[Carto] RE: Sample MRI File - Version 0.12

[Miller, Craig]

Landon,

I'd encourage you to take a look at the XML format that Mapguide Open
Source uses.  It supports multiple renderers (AGG, GD, etc) and has an
excellent XML specification.  The goal was to make it as capable as
AutoCAD.

Craig


On Fri, Jan 7, 2011 at 1:30 PM, Landon Blake <lblake at ksninc.com> wrote:
> 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
>
>
> 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
>
>



-- 
Craig Miller
Geospatial Software Architect