[Carto] Requesting Tentative Consensus on MRI File Format - Version 0.12

[Landon Blake]

Thanks for your comments Laurent. Your timing is great, since I was going to start on the MRI parsing code today.

You wrote: "Hello Landon, if i understand the MRI xml file well, it regroups the three functional blocs of the wiki diagram (Styling, Output and Layout) in a single file."

I think this is how things evolved. Do we want to split things up into separate files?

You wrote: "It may be theoretical, but can't we think about a more flexible layout definition ? For example the inner frames could be positioned relatively to the sides of the document and dimensioned proportionally (like it's done in the flexbuilder design tool, or netbeans java editor). On the wiki page i read the possibility of a "Graphical Style & Layout Editor".

What i propose is to leave the possibility to help the user to design the map, by letting him or her place and dimension the elements without going into the details. Perhaps it's better done upstream, into the mapping application / designing, than into the "better print" step ? In other words is the layout to be precisely fixed before the map rendering engine enter into action?"

I think the final MRI file needs to be precisely defined. I think we will likely end up with graphical user interface applications that allow the map layout to be defined by the user without hand coding top-left corner coordinates in an XML file. In this type of scenario the user might just drag components onto a canvas and the GUI application would do the math to write the MRI file.

Does this make sense? 

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.

You wrote: "Another idea, perhaps more useful : can we imagine levels of transparency applied to the frames ? It's useful when legends are in several frames and not embedded into the map layers frame, and when the user wants to add textual frames above the map. (There are several types of transparency and merging types, think about photoshop blending modes)."

I didn't think about frames displayed "on top" of each other. This is quite common for map details or inset maps. I agree it would be good to have a z-order or level element on the map frame. Do we need transparency though? In what situation would you need an embedded map frame to be transparent?

Thank you again for your comments. They were great.

Landon
 
________________________________________
From: ljegou at gmail.com [mailto:ljegou at gmail.com] On Behalf Of Laurent Jégou
Sent: Sunday, May 02, 2010 1:48 AM
To: Landon Blake
Cc: carto at lists.osgeo.org
Subject: Re: [Carto] Requesting Tentative Consensus on MRI File Format - Version 0.12

Hello Landon, if i understand the MRI xml file well, it regroups the three functional blocs of the wiki diagram (Styling, Output and Layout) in a single file.

The map described by this file seems to be very precisely designed, or its layout described.

It may be theoretical, but can't we think about a more flexible layout definition ? For example the inner frames could be positioned relatively to the sides of the document and dimensioned proportionally (like it's done in the flexbuilder design tool, or netbeans java editor). On the wiki page i read the possibility of a "Graphical Style & Layout Editor".

What i propose is to leave the possibility to help the user to design the map, by letting him or her place and dimension the elements without going into the details. Perhaps it's better done upstream, into the mapping application / designing, than into the "better print" step ? In other words is the layout to be precisely fixed before the map rendering engine enter into action ?

Another idea, perhaps more useful : can we imagine levels of transparency applied to the frames ? It's useful when legends are in several frames and not embedded into the map layers frame, and when the user wants to add textual frames above the map. (There are several types of transparency and merging types, think about photoshop blending modes).

The "stripped down" MRI file seems ok to me, but on the other hand the specifications should be developped.

Thanks,

-- 
Laurent Jégou
Cartographe et enseignant
UTM - Dépt. Géographie
31058 TOULOUSE Cedex 9 - 05.61.50.43.89
http://www.univ-tlse2.fr/geoprdc


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.