<html>
<head>
</head>
<body style="font-weight: normal; margin-bottom: 1px; margin-right: 4px; font-family: Comic Sans MS; margin-top: 4px; font-style: normal; line-height: normal; font-size: 12pt; font-variant: normal; margin-left: 4px">
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">All,</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">I know this is going to sound like a step backwards, but should be do a capabilities diagram of things desired vs what might be available else where to make the determination of what should/shouldn't/couldn't be included?</font> </p>
<br>
<p style="margin-top: 0; margin-bottom: 0">
<font face="Comic Sans MS" size="3">bobb</font> </p>
<br> <br>
<p style="margin-top: 0; margin-bottom: 0">
<br>
<br>
>>> "Miller, Craig" <craig.miller@spatialminds.com> wrote:<br> </p>
<table border="0" style="margin-bottom: 0; margin-right: 0; margin-top: 0; margin-left: 15px; font-size: 1em" bgcolor="#f3f3f3">
<tr>
<td>
<div style="border-left: solid 1px #050505; padding-left: 7px">
<p style="margin-top: 0; margin-bottom: 0">
Yes, that's the main print layout schema.  My understanding of this<br>project (this mailing list) is that the goal is to specify a common<br>XML format for printing/rendering and to produce a rendering engine<br>that can support it.  So, along those lines I thought we might also<br>want to use the other portions of their schema to represent layer<br>definitions, datasources, stylization rules, etc.<br><br><br>In addition to your link here's a few links that seem relevant:<br><br>XSDs:  <a href="http://trac.osgeo.org/mapguide/browser/branches/2.1/MgDev/Common/Schema">http://trac.osgeo.org/mapguide/browser/branches/2.1/MgDev/Common/Schema</a><br><br>The original spec:  <a href="http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14">http://trac.osgeo.org/mapguide/wiki/MapGuideRfc14</a><br><br>The additions:  <a href="http://trac.osgeo.org/mapguide/wiki/AdvancedStylization">http://trac.osgeo.org/mapguide/wiki/AdvancedStylization</a><br><br>Craig<br><br>On Sat, Jan 8, 2011 at 8:38 AM, Tyler Mitchell (OSGeo)<br><tmitchell@osgeo.org> wrote:<br>> Craig, you got my attention! :)<br>> <a href="http://trac.osgeo.org/mapguide/wiki/MapGuideRfc67">http://trac.osgeo.org/mapguide/wiki/MapGuideRfc67</a><br>> Is that what you're referring to?<br>><br>> Tyler<br>><br>> On 2011-01-07, at 4:33 PM, Miller, Craig wrote:<br>><br>>> Landon,<br>>><br>>> I'd encourage you to take a look at the XML format that Mapguide Open<br>>> Source uses.  It supports multiple renderers (AGG, GD, etc) and has an<br>>> excellent XML specification.  The goal was to make it as capable as<br>>> AutoCAD.<br>>><br>>> Craig<br>>><br>>><br>>> On Fri, Jan 7, 2011 at 1:30 PM, Landon Blake <lblake@ksninc.com> wrote:<br>>>> It’s been over 7 months, but I’m finally making time to respond to Bob’s<br>>>> last set of questions on the Map Rendering Input specification. For those of<br>>>> you that have forgotten or joined this mailing list since our late spring<br>>>> discussion, let me provide a refresher. A few of us started brainstorming on<br>>>> a simple specification for an XML format that could be used as input to a<br>>>> map rendering engine. A couple of us even started to scrape together some<br>>>> code for an example implementation of an engine that would consume the input<br>>>> file and produce the map as output.<br>>>><br>>>> I’ve totally dropped the ball on further discussion and implementation of<br>>>> this idea. I’m going to try to pick the ball back up and move down the field<br>>>> again.  :]<br>>>><br>>>> Bob wrote: “Should "DPI" be considered a valid INIT type for resolution?<br>>>>  Wouldn't px, em or ?? fit better?”<br>>>><br>>>> The list of properties in the properties element will change depending on<br>>>> the type of output. In the example I used the output was an image, so I<br>>>> thought the resolution of the output image would be appropriate. I think<br>>>> this is a parameter that will be needed when converting vector data to a<br>>>> raster output format. If our output was in a vector format, like PDF or SVG,<br>>>> then the type of units you listed would certainly be correct. Your question<br>>>> made me realize we should define a standard set of properties for required<br>>>> for each type of output format. We could do this with some type of XML<br>>>> schema, but I think some plain language documentation would be more helpful<br>>>> at this point.<br>>>><br>>>> Bob wrote: “Should "width / height" really be "X / Y / (Z)" ?” I don’t see<br>>>> how a Z value would apply to page size, but it certainly would apply to map<br>>>> frames, as you suggest. If there is a way it makes sense for the page size<br>>>> section, we can include it.<br>>>><br>>>> Bob wrote: “Don't know that the "mapframes" container is needed.  Just<br>>>> process each "mapframe" inside of "mapframes" no matter what.”<br>>>><br>>>> I guess the inclusion of the mapframes element is because I’m thinking like<br>>>> a Java programmer? To me the mapframes element is like a collection or<br>>>> container. I think this element would make parsing the MRI file easier in<br>>>> object-oriented programming languages. If I was parsing it in Java I would<br>>>> have a MapFrames object with a method that returned the number of MapFrames,<br>>>> as an example. But if there is a benefit from taking it out we can do that<br>>>> too.<br>>>><br>>>> Bob wrote: “Are unique "SECTION name=" defaulted to requiring unique values,<br>>>> should NAME be moved out of PARAM status?  For more than one Section of type<br>>>> "LAYOUT" for example.”<br>>>><br>>>> I don’t think that section names have to be unique. You should be able to<br>>>> include multiple layouts in a single MRI file.<br>>>><br>>>> Bob wrote: “Mapframe Stacking isn't accounted for (z order) for more than<br>>>> one MapFrame, might want to display on mapframe partial over another.  Could<br>>>> get away with sending a polygon instead of width / height - X / Y, although<br>>>> that would get messy quick  Might have to bite the bullet there though.<br>>>>  Another use for this, would be to print out a result on top of a template<br>>>> that might already contain a MAPFRAME of the same name.  The stacking would<br>>>> become needed in this situation too I think.  Over or under the template?”<br>>>><br>>>> We should add mapframe Z-order, or stacking, to the MRI file.<br>>>><br>>>> Bob wrote: “ I'm lost on the mapframe>scale value, what to what, relative to<br>>>> what?  Should the unit size be passed in for the Model_space_position as<br>>>> well to make this work? “<br>>>><br>>>><br>>>><br>>>> I would use this value to figure out how to scale vector data in a real<br>>>> world coordinate system to the page coordinate system. So in the example<br>>>> given, I would need to scale model space geometry by 1/1000 to make it land<br>>>> on the right place in the page. I think if we leave the scale value<br>>>> unitless, the model space position can remain unitless as well.<br>>>><br>>>><br>>>><br>>>> Bob wrote: “Should mapframe properties be referenced to a mapframe  like :<br>>>> <map_frame_properties mapframe="Main Map Frame">?”<br>>>><br>>>><br>>>><br>>>> I don’t think this is necessary since the mapframe properties element is a<br>>>> child of the map frame element. That parent-child relationship should make<br>>>> the association clear.<br>>>><br>>>><br>>>><br>>>> Bob wrote:<br>>>><br>>>> “<br>>>><br>>>> *  Set up more than one Map view in this example . . . Will help with<br>>>> referencing question I have above.<br>>>><br>>>> *  Captioning for Mapframes.<br>>>><br>>>> *  Stat's block, for outputting in text form, the descriptive elements of<br>>>> the print.<br>>>><br>>>> *  There was mention of adding in the Time of day to the date, I would<br>>>> second this.<br>>>><br>>>> *  Add metadata sub section to each layer.<br>>>><br>>>> “<br>>>><br>>>><br>>>><br>>>> Everything you suggested in the above list sounds good, except I don’t know<br>>>> what you mean by a stats block.<br>>>><br>>>><br>>>><br>>>> I’ve attached a new MRI file with the following changes:<br>>>><br>>>><br>>>><br>>>> -          Added a second map frame.<br>>>><br>>>> -          Added map frame z-order.<br>>>><br>>>> -          Added polygonal map frame.<br>>>><br>>>> -          Added map frame captions.<br>>>><br>>>> -          Added map frame borders.<br>>>><br>>>> -          Added text styles, border styles, and colors.<br>>>><br>>>> -          Moved layers to a separate section and replaced list of layer<br>>>> objects in map frame properties with a list of layer names and z order. This<br>>>> allows layers to be reused in multiple map frames by reference.<br>>>><br>>>><br>>>><br>>>> Let’s tear this version apart. After we think we’ve got something we can<br>>>> agree on, I’ll commit this to my SVN as version 0.13. Then I’d like to take<br>>>> a break, before the spec gets a lot more complicated, to get a<br>>>> implementation working. I have the feeling we may be tweaking the spec after<br>>>> we try to write some code. I’d really like to get an example implementation<br>>>> of an engine that can consume our 0.13 version MRI and spit out a simple SVG<br>>>> file.<br>>>><br>>>><br>>>><br>>>> Once we get that working we can come back and add more stuff to the spec,<br>>>> like annotations, legend, embedded images for logos, grid lines, symbols,<br>>>> and the like.<br>>>><br>>>><br>>>><br>>>> Landon<br>>>><br>>>><br>>>><br>>>> P.S. – Is George still interested in a C# implementation of an MRI engine?<br>>>> Please let me know so I can start working on the code (again). :]<br>>>><br>>>><br>>>><br>>>> From: Bob Basques [mailto:Bob.Basques@ci.stpaul.mn.us]<br>>>> Sent: Monday, May 03, 2010 11:41 AM<br>>>> To: Landon Blake; carto@lists.osgeo.org; Tyler Mitchell (OSGeo)<br>>>> Subject: Re: Sample MRI File - Version 0.12<br>>>><br>>>><br>>>><br>>>> All,<br>>>><br>>>><br>>>><br>>>> Ok, looking through it. . . .BTW, I'm looking at things with respect to PDF<br>>>> output (Including 3D models eventually).<br>>>><br>>>><br>>>><br>>>> Comments on Spec:<br>>>><br>>>><br>>>><br>>>> *  Should "DPI" be considered a valid INIT type for resolution?  Wouldn't<br>>>> px, em or ?? fit better?<br>>>><br>>>> *  Should "width / height" really be "X / Y / (Z)" ?<br>>>><br>>>> *  Don't know that the "mapframes" container is needed.  Just process each<br>>>> "mapframe" inside of "mapframes" no matter what.<br>>>><br>>>> *  Are unique "SECTION name=" defaulted to requiring unique values, should<br>>>> NAME be moved out of PARAM status?  For more than one Section of type<br>>>> "LAYOUT" for example.<br>>>><br>>>> *  Mapframe Stacking isn't accounted for (z order) for more than one<br>>>> MapFrame, might want to display on mapframe partial over another.  Could get<br>>>> away with sending a polygon instead of width / height - X / Y, although that<br>>>> would get messy quick  Might have to bite the bullet there though.  Another<br>>>> use for this, would be to print out a result on top of a template that might<br>>>> already contain a MAPFRAME of the same name.  The stacking would become<br>>>> needed in this situation too I think.  Over or under the template?<br>>>><br>>>> *  I'm lost on the mapframe>scale value, what to what, relative to what?<br>>>>  Should the unit size be passed in for the Model_space_position as well to<br>>>> make this work?<br>>>><br>>>> *  Should mapframe properties be referenced to a mapframe  like :<br>>>> <map_frame_properties mapframe="Main Map Frame"><br>>>><br>>>><br>>>><br>>>> Suggested additions:<br>>>><br>>>><br>>>><br>>>> *  Set up more than one Map view in this example . . . Will help with<br>>>> referencing question I have above.<br>>>><br>>>> *  Captioning for Mapframes.<br>>>><br>>>> *  Stat's block, for outputting in text form, the descriptive elements of<br>>>> the print.<br>>>><br>>>> *  There was mention of adding in the Time of day to the date, I would<br>>>> second this.<br>>>><br>>>> *  Add metadata sub section to each layer.<br>>>><br>>>><br>>>><br>>>> bobb<br>>>><br>>>><br>>>>>>> "Landon Blake" <lblake@ksninc.com> wrote:<br>>>><br>>>> I don't think that is the most current XML file. Try the attached.<br>>>><br>>>> Landon<br>>>> Office Phone Number: (209) 946-0268<br>>>> Cell Phone Number: (209) 992-0658<br>>>><br>>>><br>>>> ________________________________________<br>>>> From: carto-bounces@lists.osgeo.org [mailto:carto-bounces@lists.osgeo.org]<br>>>> On Behalf Of Bob Basques<br>>>> Sent: Monday, May 03, 2010 11:02 AM<br>>>> To: carto@lists.osgeo.org; Tyler Mitchell (OSGeo)<br>>>> Subject: Re: [Carto] Requesting Tentative Consensus on MRI FileFormat-<br>>>> Version 0.12<br>>>><br>>>> Is this the latest stuff being talked about?<br>>>><br>>>> <a href="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_stripped_version_0-11-0001.xml</a><br>>>><br>>>> <a href="http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes-0001.obj">http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes-0001.obj</a>  (really<br>>>> a PDF . . )<br>>>><br>>>><br>>>>>>> "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org> wrote:<br>>>> On 05/03/2010 10:23 AM, Landon Blake wrote:<br>>>>> We could certainly define "dynamic" components using proportions and<br>>>>> anchoring, but that will increase the complexity of the map rendering<br>>>>> engine quite a bit. I'd prefer to see that done in the prior step by<br>>>>> a nother program in the tool chain.<br>>>>><br>>>>> That just my opinion though.<br>>>><br>>>> I sure agree.  Anything that has a user interface can be considered<br>>>> slightly off-topic for now at least.  The hope is to solidify an XML<br>>>> specification and then let others build to the specification.<br>>>><br>>>> Of course, once we have it settled, then I'm sure several of us will<br>>>> want to try various approaches and report back here :)<br>>>> _______________________________________________<br>>>> Carto mailing list<br>>>> Carto@lists.osgeo.org<br>>>> <a href="http://lists.osgeoorg/mailman/listinfo/carto">http://lists.osgeoorg/mailman/listinfo/carto</a><br>>>><br>>>><br>>>> Warning:<br>>>> Information provided via electronic media is not guaranteed against defects<br>>>> including translation and transmission errors. If the reader is not the<br>>>> intended recipient, you are hereby notified that any dissemination,<br>>>> distribution or copying of this communication is strictly prohibited. If you<br>>>> have received this information in error, please notify the sender<br>>>> immediately.<br>>>><br>>>> _______________________________________________<br>>>> Carto mailing list<br>>>> Carto@lists.osgeo.org<br>>>> <a href="http://lists.osgeo.org/mailman/listinfo/carto">http://lists.osgeo.org/mailman/listinfo/carto</a><br>>>><br>>>><br>>><br>>><br>>><br>>> --<br>>> Craig Miller<br>>> Geospatial Software Architect<br>>> _______________________________________________<br>>> Carto mailing list<br>>> Carto@lists.osgeo.org<br>>> <a href="http://lists.osgeo.org/mailman/listinfo/carto">http://lists.osgeo.org/mailman/listinfo/carto</a><br>><br>><br><br><br><br>--<br>Craig Miller<br>Geospatial Software Architect<br>_______________________________________________<br>Carto mailing list<br>Carto@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/carto">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
</p>
</div>
</td>
</tr>
</table>
</body>
</html>