[Carto] RE: Sample MRI File - Version 0.12

[Miller, Craig]

Yes, that's the main print layout schema.  My understanding of this
project (this mailing list) is that the goal is to specify a common
XML format for printing/rendering and to produce a rendering engine
that can support it.  So, along those lines I thought we might also
want to use the other portions of their schema to represent layer
definitions, datasources, stylization rules, etc.


In addition to your link here's a few links that seem relevant:

XSDs:  http://trac.osgeo.org/mapguide/browser/branches/2.1/MgDev/Common/Schema

The original spec:  http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14

The additions:  http://trac.osgeo.org/mapguide/wiki/AdvancedStylization

Craig

On Sat, Jan 8, 2011 at 8:38 AM, Tyler Mitchell (OSGeo)
<tmitchell at osgeo.org> wrote:
> Craig, you got my attention! :)
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc67
> Is that what you're referring to?
>
> Tyler
>
> On 2011-01-07, at 4:33 PM, Miller, Craig wrote:
>
>> 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
>> _______________________________________________
>> Carto mailing list
>> Carto at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/carto
>
>



-- 
Craig Miller
Geospatial Software Architect