[Carto] RE: Sample MRI File - Version 0.12
Bob Basques
Bob.Basques at ci.stpaul.mn.us
Fri Jan 7 16:59:47 EST 2011
Geez, I had to scratch my head for a few seconds, it's been so long
since the thread started. Landon, I haven't got a clue what I meant by
the Stat's block, other than maybe something that described the layout,
sort of like metadata or something.
Anyway, looking at the old thread now . . .
bobb
>>> George Silva <georger.silva at gmail.com> wrote:
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 mes
sy 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/d9fffee3/attachment-0001.html
More information about the Carto
mailing list