[Carto] Sample Map Rendering Input File

[Landon Blake]

Tyler wrote: " Hehe - you're a fast mover Landon :)  Hopefully others on
the list get a chance to pipe up before the project is completed.  ;-)
High five on the enthusiasm .. wahoo!"

Maybe I should cool my jets a little bit. I do have other things to work
on. :]

I suppose my enthusiasm stems from having this concept align very
closely to an itch I'm scratching in OpenJUMP right now. That may have
made me a little too zealous. I certainly want other people to have some
input.

Tyler wrote: "Can you outline OpenJump's API for map, layer, style
objects?"

OpenJUMP has more of a map rendering system for the application than it
does a printing system, thought the same concept applies (converting
raster data in a world coordinate system to raster data in a
device/paper coordinate system.) OpenJUMP essentially takes JTS geometry
objects, converts them to Java 2D objects, and paints them on a GUI
canvas from Swing.

Tyler wrote: "I appreciate trying to tackle the questions with Python,
but think we might get ahead of ourselves.  For example, I'd like to
look at MApnik's API/model before rolling something of your own - I'm
sure we are not trying to re-invent a rendering engine.

That said, carry on, these are good questions, but other application
frameworks have dealt with them before of course.

I'm partial to Python with GDAL/OGR, but aside from that I'd look to
MapServer or Mapnik to do the rendering.  They both have Python APIs, so
for testing you can go a lot quickly with little work.  I remember a few
people complaining about MapServer's Python bindings and API but it's
been a while since I thought about these things."

I think I need to set back and let things stew a little bit without so
much stirring on my part. I'll keep moving forward with my code for OJ
while keeping an eye on the spec that develops from this project. It is
certainly something I will want to support in OJ. Even the crude map
rendering input file we've come up with so far has helped me with the
design of my code for OpenJUMP.

If some Python code comes together, plugging into Mapnik or Mapserver,
I'll definitely want to see how it works. I know there will be lots to
learn there, and likely some things that can be applied to OpenJUMP.

But you are correct in saying that reuse is best. I don't know much
about Mapserver, Mapnik, OGR/GDAL or Python, so I should wait for others
with more knowledge to take the lead.

I appreciate the chance to participate in this discussion and apologize
if I became a little overbearing in my excitement!

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 

-----Original Message-----
From: Tyler Mitchell (OSGeo) [mailto:tmitchell at osgeo.org] 
Sent: Thursday, April 08, 2010 8:43 PM
To: Landon Blake
Cc: Carlos Gabriel Asato; carto at lists.osgeo.org
Subject: Re: [Carto] Sample Map Rendering Input File

Landon Blake wrote:
> It sounds like Python is the winner.

Hehe - you're a fast mover Landon :)  Hopefully others on the list get a
chance to pipe up before the project is completed.  ;-) High five on the
enthusiasm .. wahoo!

I'd like to see a few more examples of existing APIs that model what
we're after.  Can you outline OpenJump's API for map, layer, style
objects?  The reason being that if other apps have an API modeling our
needs, then we wouldn't make a new one.

I appreciate trying to tackle the questions with Python, but think we
might get ahead of ourselves.  For example, I'd like to look at MApnik's
API/model before rolling something of your own - I'm sure we are not
trying to re-invent a rendering engine.

That said, carry on, these are good questions, but other application
frameworks have dealt with them before of course.

I'm partial to Python with GDAL/OGR, but aside from that I'd look to
MapServer or Mapnik to do the rendering.  They both have Python APIs, so
for testing you can go a lot quickly with little work.  I remember a few
people complaining about MapServer's Python bindings and API but it's
been a while since I thought about these things.




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.