[Carto] RE: Sample MRI File - Version 0.12

Fri Jan 7 17:04:49 EST 2011

My fault for taking so long to get back to you. It sounds like George is still interested in working with me on an implementation example, so your feedback will be helpful.

Thanks Bob.

Landon

Mobile: (209) 992-0658

Office: (209) 946-0268

From: Bob Basques [mailto:Bob.Basques at ci.stpaul.mn.us] 
Sent: Friday, January 07, 2011 2:00 PM
To: George Silva; Landon Blake
Cc: carto at lists.osgeo.org
Subject: Re: [Carto] RE: Sample MRI File - Version 0.12

Geez, I had to scratch my head for a few seconds, it's been so long since the thread started.  Landon, I haven't got a clue what I meant by the Stat's block, other than maybe something that described the layout, sort of like metadata or something. 

Anyway, looking at the old thread now . . . 

bobb 

>>> George Silva <georger.silva at gmail.com> wrote:

Hello guys! 

I know it's been a long time and the project has gone a little slow. Right now I'm really busy, but I can make to (re)start coding. 

Landon, do you have some sort of IM so we can exchange some real-time messages? That would help. Let me know your IM and time choice. 

Cheers, 

George

On Fri, Jan 7, 2011 at 6:31 PM, Landon Blake <lblake at ksninc.com> wrote:

	It would help if I attached the Version 0.13 file. 

	From: carto-bounces at lists.osgeo.org [mailto:carto-bounces at lists.osgeo.org] On Behalf Of Landon Blake
	Sent: Friday, January 07, 2011 1:31 PM
	To: Bob Basques
	Cc: carto at lists.osgeo.org
	Subject: [Carto] RE: Sample MRI File - Version 0.12 

	It’s been over 7 months, but I’m finally making time to respond to Bob’s last set of questions on the Map Rendering Input specification. For those of you that have forgotten or joined this mailing list since our late spring discussion, let me provide a refresher. A few of us started brainstorming on a simple specification for an XML format that could be used as input to a map rendering engine. A couple of us even started to scrape together some code for an example implementation of an engine that would consume the input file and produce the map as output. 

	I’ve totally dropped the ball on further discussion and implementation of this idea. I’m going to try to pick the ball back up and move down the field again. :] 

	Bob wrote: “Should "DPI" be considered a valid INIT type for resolution? Wouldn't px, em or ?? fit better?” 

	The list of properties in the properties element will change depending on the type of output. In the example I used the output was an image, so I thought the resolution of the output image would be appropriate. I think this is a parameter that will be needed when converting vector data to a raster output format. If our output was in a vector format, like PDF or SVG, then the type of units you listed would certainly be correct. Your question made me realize we should define a standard set of properties for required for each type of output format. We could do this with some type of XML schema, but I think some plain language documentation would be more helpful at this point. 

	Bob wrote: “Should "width / height" really be "X / Y / (Z)" ?” I don’t see how a Z value would apply to page size, but it certainly would apply to map frames, as you suggest. If there is a way it makes sense for the page size section, we can include it. 

	Bob wrote: “Don't know that the "mapframes" container is needed. Just process each "mapframe" inside of "mapframes" no matter what.” 

	I guess the inclusion of the mapframes element is because I’m thinking like a Java programmer? To me the mapframes element is like a collection or container. I think this element would make parsing the MRI file easier in object-oriented programming languages. If I was parsing it in Java I would have a MapFrames object with a method that returned the number of MapFrames, as an example. But if there is a benefit from taking it out we can do that too. 

	Bob wrote: “Are unique "SECTION name=" defaulted to requiring unique values, should NAME be moved out of PARAM status? For more than one Section of type "LAYOUT" for example.” 

	I don’t think that section names have to be unique. You should be able to include multiple layouts in a single MRI file. 

	Bob wrote: “Mapframe Stacking isn't accounted for (z order) for more than one MapFrame, might want to display on mapframe partial over another. Could get away with sending a polygon instead of width / height - X / Y, although that would get messy quick Might have to bite the bullet there though. Another use for this, would be to print out a result on top of a template that might already contain a MAPFRAME of the same name. The stacking would become needed in this situation too I think. Over or under the template?” 

	We should add mapframe Z-order, or stacking, to the MRI file. 

	Bob wrote: “ I'm lost on the mapframe>scale value, what to what, relative to what? Should the unit size be passed in for the Model_space_position as well to make this work? “ 

	I would use this value to figure out how to scale vector data in a real world coordinate system to the page coordinate system. So in the example given, I would need to scale model space geometry by 1/1000 to make it land on the right place in the page. I think if we leave the scale value unitless, the model space position can remain unitless as well. 

	Bob wrote: “Should mapframe properties be referenced to a mapframe like : <map_frame_properties mapframe="Main Map Frame">?” 

	I don’t think this is necessary since the mapframe properties element is a child of the map frame element. That parent-child relationship should make the association clear. 

	Bob wrote: 

	“ 

	* Set up more than one Map view in this example . . . Will help with referencing question I have above. 

	* Captioning for Mapframes. 

	* Stat's block, for outputting in text form, the descriptive elements of the print. 

	* There was mention of adding in the Time of day to the date, I would second this. 

	* Add metadata sub section to each layer. 

	“ 

	Everything you suggested in the above list sounds good, except I don’t know what you mean by a stats block. 

	I’ve attached a new MRI file with the following changes: 

	- Added a second map frame. 

	- Added map frame z-order. 

	- Added polygonal map frame. 

	- Added map frame captions. 

	- Added map frame borders. 

	- Added text styles, border styles, and colors. 

	- Moved layers to a separate section and replaced list of layer objects in map frame properties with a list of layer names and z order. This allows layers to be reused in multiple map frames by reference. 

	Let’s tear this version apart. After we think we’ve got something we can agree on, I’ll commit this to my SVN as version 0.13. Then I’d like to take a break, before the spec gets a lot more complicated, to get a implementation working. I have the feeling we may be tweaking the spec after we try to write some code. I’d really like to get an example implementation of an engine that can consume our 0.13 version MRI and spit out a simple SVG file. 

	Once we get that working we can come back and add more stuff to the spec, like annotations, legend, embedded images for logos, grid lines, symbols, and the like. 

	Landon 

	P.S. – Is George still interested in a C# implementation of an MRI engine? Please let me know so I can start working on the code (again). :] 

	From: Bob Basques [mailto:Bob.Basques at ci.stpaul.mn.us]
	Sent: Monday, May 03, 2010 11:41 AM
	To: Landon Blake; carto at lists.osgeo.org; Tyler Mitchell (OSGeo)
	Subject: Re: Sample MRI File - Version 0.12 

	All, 

	Ok, looking through it. . . .BTW, I'm looking at things with respect to PDF output (Including 3D models eventually). 

	Comments on Spec: 

	* Should "DPI" be considered a valid INIT type for resolution? Wouldn't px, em or ?? fit better? 

	* Should "width / height" really be "X / Y / (Z)" ? 

	* Don't know that the "mapframes" container is needed. Just process each "mapframe" inside of "mapframes" no matter what. 

	* Are unique "SECTION name=" defaulted to requiring unique values, should NAME be moved out of PARAM status? For more than one Section of type "LAYOUT" for example. 

	* Mapframe Stacking isn't accounted for (z order) for more than one MapFrame, might want to display on mapframe partial over another. Could get away with sending a polygon instead of width / height - X / Y, although that would get messy quick Might have to bite the bullet there though. Another use for this, would be to print out a result on top of a template that might already contain a MAPFRAME of the same name. The stacking would become needed in this situation too I think. Over or under the template? 

	* I'm lost on the mapframe>scale value, what to what, relative to what? Should the unit size be passed in for the Model_space_position as well to make this work? 

	* Should mapframe properties be referenced to a mapframe like : <map_frame_properties mapframe="Main Map Frame"> 

	Suggested additions: 

	* Set up more than one Map view in this example . . . Will help with referencing question I have above. 

	* Captioning for Mapframes. 

	* Stat's block, for outputting in text form, the descriptive elements of the print. 

	* There was mention of adding in the Time of day to the date, I would second this. 

	* Add metadata sub section to each layer. 

	bobb 

	>>> "Landon Blake" <lblake at ksninc.com> wrote: 

	I don't think that is the most current XML file. Try the attached.

	Landon
	Office Phone Number: (209) 946-0268
	Cell Phone Number: (209) 992-0658

	________________________________________
	From: carto-bounces at lists.osgeo.org [mailto:carto-bounces at lists.osgeo.org] On Behalf Of Bob Basques
	Sent: Monday, May 03, 2010 11:02 AM
	To: carto at lists.osgeo.org; Tyler Mitchell (OSGeo)
	Subject: Re: [Carto] Requesting Tentative Consensus on MRI FileFormat- Version 0.12

	Is this the latest stuff being talked about?

	http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/mri_stripped_version_0-11-0001.xml

	http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes-0001.obj (really a PDF . . )

	>>> "Tyler Mitchell (OSGeo)" <tmitchell at osgeo.org> wrote:
	On 05/03/2010 10:23 AM, Landon Blake wrote:
	> We could certainly define "dynamic" components using proportions and
	> anchoring, but that will increase the complexity of the map rendering
	> engine quite a bit. I'd prefer to see that done in the prior step by
	> a nother program in the tool chain.
	>
	> That just my opinion though.

	I sure agree. Anything that has a user interface can be considered
	slightly off-topic for now at least. The hope is to solidify an XML
	specification and then let others build to the specification.

	Of course, once we have it settled, then I'm sure several of us will
	want to try various approaches and report back here :)
	_______________________________________________
	Carto mailing list
	Carto at lists.osgeo.org
	http://lists.osgeoorg/mailman/listinfo/carto <http://lists.osgeo.org/mailman/listinfo/carto> 

	Warning:
	Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. 

	_______________________________________________
	Carto mailing list
	Carto at lists.osgeo.org
	http://lists.osgeo.org/mailman/listinfo/carto

--
George R. C. Silva

Desenvolvimento em GIS
http://blog.geoprocessamento.net

Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/carto/attachments/20110107/885eee87/attachment-0001.html