<div>Hello guys!</div>
<div> </div>
<div>I know it's been a long time and the project has gone a little slow. Right now I'm really busy, but I can make to (re)start coding.</div>
<div> </div>
<div>Landon, do you have some sort of IM so we can exchange some real-time messages? That would help. Let me know your IM and time choice.</div>
<div> </div>
<div>Cheers,</div>
<div> </div>
<div>George<br></div>
<div class="gmail_quote">On Fri, Jan 7, 2011 at 6:31 PM, Landon Blake <span dir="ltr"><<a href="mailto:lblake@ksninc.com">lblake@ksninc.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div style="MARGIN: 3pt 3pt 0.75pt" lang="EN-US" vlink="purple" link="blue">
<div>
<p class="MsoNormal"><span style="COLOR: #1f497d; FONT-SIZE: 11pt">It would help if I attached the Version 0.13 file.</span></p>
<div>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"><b><span style="FONT-SIZE: 10pt">From:</span></b><span style="FONT-SIZE: 10pt"> <a href="mailto:carto-bounces@lists.osgeo.org" target="_blank">carto-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:carto-bounces@lists.osgeo.org" target="_blank">carto-bounces@lists.osgeo.org</a>] <b>On Behalf Of </b>Landon Blake<br>
<b>Sent:</b> Friday, January 07, 2011 1:31 PM<br><b>To:</b> Bob Basques<br><b>Cc:</b> <a href="mailto:carto@lists.osgeo.org" target="_blank">carto@lists.osgeo.org</a><br><b>Subject:</b> [Carto] RE: Sample MRI File - Version 0.12</span></p>
</div></div>
<div>
<div></div>
<div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">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.</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">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. :]</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">Bob wrote: “Should "DPI" be considered a valid INIT type for resolution? Wouldn't px, em or ?? fit better?”</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">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.</span></p>
<p><span style="FONT-SIZE: 11pt">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.</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">Bob wrote: “Don't know that the "mapframes" container is needed. Just process each "mapframe" inside of "mapframes" no matter what.”</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">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.</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">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.”</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">I don’t think that section names have to be unique. You should be able to include multiple layouts in a single MRI file.</span></p>
<p style="MARGIN-BOTTOM: 12pt" class="MsoNormal"><span style="FONT-SIZE: 11pt">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?”</span></p>
<p class="MsoNormal"><span style="FONT-SIZE: 11pt">We should add mapframe Z-order, or stacking, to the MRI file.</span></p>
<p><span style="FONT-SIZE: 11pt">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? “</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">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. </span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">Bob wrote: “Should mapframe properties be referenced to a mapframe like : <map_frame_properties mapframe="Main Map Frame">?”</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">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.</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">Bob wrote:</span></p>
<p><span style="FONT-SIZE: 11pt">“</span></p>
<p><span style="FONT-SIZE: 11pt">* Set up more than one Map view in this example . . . Will help with referencing question I have above. </span></p>
<p><span style="FONT-SIZE: 11pt">* Captioning for Mapframes. </span></p>
<p><span style="FONT-SIZE: 11pt">* Stat's block, for outputting in text form, the descriptive elements of the print. </span></p>
<p><span style="FONT-SIZE: 11pt">* There was mention of adding in the Time of day to the date, I would second this. </span></p>
<p><span style="FONT-SIZE: 11pt">* Add metadata sub section to each layer. </span></p>
<p><b><span style="FONT-SIZE: 11pt">“</span></b></p>
<p><b><span style="FONT-SIZE: 11pt"> </span></b></p>
<p><span style="FONT-SIZE: 11pt">Everything you suggested in the above list sounds good, except I don’t know what you mean by a stats block.</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">I’ve attached a new MRI file with the following changes:</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added a second map frame.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added map frame z-order.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added polygonal map frame.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added map frame captions.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added map frame borders.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">Added text styles, border styles, and colors.</span></p>
<p style="MARGIN-LEFT: 0.5in"><span style="FONT-SIZE: 11pt"><span>-<span style="FONT: 7pt 'Times New Roman'"> </span></span></span><span style="FONT-SIZE: 11pt">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.</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">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.</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">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.</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">Landon</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<p><span style="FONT-SIZE: 11pt">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). :]</span></p>
<p><span style="FONT-SIZE: 11pt"> </span></p>
<div>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"><b><span style="FONT-SIZE: 10pt">From:</span></b><span style="FONT-SIZE: 10pt"> Bob Basques [mailto:<a href="mailto:Bob.Basques@ci.stpaul.mn.us" target="_blank">Bob.Basques@ci.stpaul.mn.us</a>] <br>
<b>Sent:</b> Monday, May 03, 2010 11:41 AM<br><b>To:</b> Landon Blake; <a href="mailto:carto@lists.osgeo.org" target="_blank">carto@lists.osgeo.org</a>; Tyler Mitchell (OSGeo)<br><b>Subject:</b> Re: Sample MRI File - Version 0.12</span></p>
</div></div>
<p class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">All,</span> </p>
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">Ok, looking through it. . . .BTW, I'm looking at things with respect to PDF output (Including 3D models eventually).</span> </p>
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">Comments on Spec:</span> </p>
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Should "DPI" be considered a valid INIT type for resolution? Wouldn't px, em or ?? fit better?</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Should "width / height" really be "X / Y / (Z)" ?</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Don't know that the "mapframes" container is needed. Just process each "mapframe" inside of "mapframes" no matter what.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* 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.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* 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?</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* 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?</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Should mapframe properties be referenced to a mapframe like : <map_frame_properties mapframe="Main Map Frame"></span> </p>
<p style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">Suggested additions:</span> </p>
<p style="MARGIN: 0in 0in 0pt" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Set up more than one Map view in this example . . . Will help with referencing question I have above.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Captioning for Mapframes.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Stat's block, for outputting in text form, the descriptive elements of the print.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* There was mention of adding in the Time of day to the date, I would second this.</span> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">* Add metadata sub section to each layer.</span> </p>
<p style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in" class="MsoNormal"> </p>
<p><span style="FONT-FAMILY: 'Comic Sans MS'">bobb</span> </p>
<p style="MARGIN-BOTTOM: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in" class="MsoNormal"> </p>
<p><br>>>> "Landon Blake" <<a href="mailto:lblake@ksninc.com" target="_blank">lblake@ksninc.com</a>> wrote:</p>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: #050505 1pt solid; PADDING-BOTTOM: 0in; PADDING-LEFT: 5pt; PADDING-RIGHT: 0in; MARGIN-LEFT: 11.25pt; BORDER-TOP: medium none; BORDER-RIGHT: medium none; PADDING-TOP: 0in">
<p style="BACKGROUND: #f3f3f3">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: <a href="mailto:carto-bounces@lists.osgeo.org" target="_blank">carto-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:carto-bounces@lists.osgeo.org" target="_blank">carto-bounces@lists.osgeo.org</a>] On Behalf Of Bob Basques<br>
Sent: Monday, May 03, 2010 11:02 AM<br>To: <a href="mailto:carto@lists.osgeo.org" target="_blank">carto@lists.osgeo.org</a>; Tyler Mitchell (OSGeo)<br>Subject: Re: [Carto] Requesting Tentative Consensus on MRI FileFormat- 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" target="_blank">http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/mri_stripped_version_0</a>-11-0001.xml<br>
<br><a href="http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes" target="_blank">http://lists.osgeo.org/pipermail/carto/attachments/20100412/a894c7f6/MRI_Changes</a>-0001.obj (really a PDF . . )<br>
<br><br>>>> "Tyler Mitchell (OSGeo)" <<a href="mailto:tmitchell@osgeo.org" target="_blank">tmitchell@osgeo.org</a>> 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><a href="mailto:Carto@lists.osgeo.org" target="_blank">Carto@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/carto" target="_blank">http://lists.osgeoorg/mailman/listinfo/carto</a><br>
<br><br>Warning:<br>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. </p>
</div></div></div></div></div><br>_______________________________________________<br>Carto mailing list<br><a href="mailto:Carto@lists.osgeo.org">Carto@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/carto" target="_blank">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>George R. C. Silva<br><br>Desenvolvimento em GIS<br><a href="http://blog.geoprocessamento.net">http://blog.geoprocessamento.net</a><br>