Hi,
Thanks for this input Martin, it makes the hard part of the problem
clearer in my mind.
I'm reading this... Cool idea, definitely. But it gets into deep
water very quickly, depending on how fancy you want to get.
I don't think there's anything in the current model that limits this per
Landon you may look at the API provided by geoscript as a more suitable target.
It does forgo the usual GIS terminology in order to try and reach a wider
range of developers. (i.e. records rather then features)
While they have implementations in several languages, if you did an
implementation
Jody:
You wrote: Landon you may look at the API provided by geoscript as a
more suitable target.
I'd never head of GeoScript, that is something I will definitely have
to check our for my work in both Python and Javascript.
If the API was too different from the existing JUMP simple feature
I'd never head of GeoScript, that is something I will definitely have
to check our for my work in both Python and Javascript.
I am interested in your take on their alternative to the feature model
(note this project is born out Justin's frustration with the GeoTools feature
model so you
Jody wrote: I am interested in your take on their alternative to the
feature model (note this project is born out Justin's frustration
with the GeoTools feature model so you are in good company).
I need to take a closer look at the API. From the bit I saw today, it
looks like they are headed in
should have copied to JPP
Original-Nachricht
Betreff: Re: [Java-collab] JUMP Lib and GeoScript
Datum: Fri, 05 Oct 2012 21:19:15 -0400
Von: Stefan Steiniger sst...@geo.uzh.ch
An: java-col...@lists.osgeo.org
Hi Landon,
now that I have read your emails, I would recommend you to
