[Carto] RE: Sample MRI File - Version 0.12
Tyler Mitchell (OSGeo)
tmitchell at osgeo.org
Sat Jan 8 11:38:43 EST 2011
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
More information about the Carto
mailing list