[Carto] RE: Sample MRI File - Version 0.12

[George Silva]

Hello guys!

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.

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.

Cheers,

George
On Fri, Jan 7, 2011 at 6:31 PM, Landon Blake <lblake at ksninc.com> wrote:

>  It would help if I attached the Version 0.13 file.
>
> *From:* carto-bounces at lists.osgeo.org [mailto:
> carto-bounces at lists.osgeo.org] *On Behalf Of *Landon Blake
> *Sent:* Friday, January 07, 2011 1:31 PM
> *To:* Bob Basques
> *Cc:* carto at lists.osgeo.org
> *Subject:* [Carto] RE: Sample MRI File - Version 0.12
>
>
>
> 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<http://lists.osgeo.org/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
>
>


-- 
George R. C. Silva

Desenvolvimento em GIS
http://blog.geoprocessamento.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/carto/attachments/20110107/5f09e4e6/attachment-0001.html