[Carto] RE: Sample MRI File - Version 0.12
Bob Basques
Bob.Basques at ci.stpaul.mn.us
Mon Jan 10 10:36:37 EST 2011
All,
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?
bobb
>>> "Miller, Craig" <craig.miller at spatialminds.com> wrote:
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 languag
es. 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,
>>> a
nd 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
_______________________________________________
Carto mailing list
Carto at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/carto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/carto/attachments/20110110/984a0596/attachment-0001.html
More information about the Carto
mailing list