Re: [Geotools-devel] Preview Experimental GPX Code

[Bolla, P. <bu...@me...>]

Hello,

Don't worry, I'm not offended that easily :)

The modules I'm talking about are the GeoTools module structure modules:

gt-xml-gpx under modules/unsupported/xml-gpx, providing packages:
org.geotools.gpx
org.geotools.gpx.bean
org.geotools.gpx.binding

and
gt-gpx under modules/unsupported/gpx, providing packages:
org.geotools.data.gpx
org.geotools.data.gpx.temporal

The first one is the low level access module, the second is the 
GeoTools/OpenGis interface.


Peter

Sunburned Surveyor wrote:
> Jody wrote: "Landon did I understand your aims correctly?"
> 
> Yes.
> 
> I did'nt realize that a gt-xml-gpx package existed, or I would have
> taken a closer look at it. I thought there was only the following
> three (3) packages:
> 
> org.geotools.gpx
> org.geotools.gpx.bean
> org.geotools.gpx.binding
> 
> I was looking here for documentation on GPX related packages:
> 
> http://javadoc.geotools.fr/2.5/
> 
> Peter wrote: "I think that you give a much greater importance to the
> low level access of the file, than you should."
> 
> As Jody stated, I think my approach evolved significant differences as
> I began to learn more about your code. It's not that your code was
> wrong, its just that I saw room for an alternative. I think the two
> approaches probably stems from our different end goals. I think you
> had UDig in mind, while I was thinking about what I could do to
> support GPX in OpenJUMP.
> 
> I was definitely interested in providing programmer friendly access at
> a lower level. This allows different FOSS programs to do with the GPX
> entities what they desire. I couldn't do this if I only provided a
> GeoTools SimpleFeature implementation from GPX files.
> 
> That's why I figured I should start playing around in a separate
> package structure, and in the SurveyOS SVN repository, at least to
> start.
> 
> I hope I haven't offended Peter. His code inspired me to work on
> supporting GPX for OpenJUMP. I'll complete my little experiment in the
> next few weeks and will then have interested programmers take another
> look.
> 
> Landon
> 
> 
> 
> On Fri, May 23, 2008 at 10:24 AM, Jody Garnett <jga...@re...> wrote:
>> That is an approach we take often Peter; for example the gt-wps module is
>> going to offer a "no abstraction" access to a web processing service. Then a
>> high level gt-process module can offer the easier api for Java programmers.
>>
>> Landon is trying to do something slightly different (ie he has different
>> goals):
>> - he wants a low level data access api that he can share with other
>> communities
>> - he wants to layer the high level geotools datastore api on top of it
>>
>> Landon did I understand your aims correctly?
>> Jody
>>> Hello,
>>>
>>> I think that you give a much greater importance to the low level access of
>>> the file, than you should. I'm not a GeoTools expert, but my understanding
>>> is that the point in the whole thing is to generalize the way the data could
>>> be accessed. This is why I didn't care about names of propertyes, but let
>>> them reflect to the element names in the file (wpt, trk, rte). Also, the
>>> gt-xml-gpx module is the low level access modul, that parses the file into
>>> java objects, and vice versa, and there is a gt-gpx module, which supports
>>> the GeoTools data access interface implementations, and translates between
>>> the low level gpx java objects, and higher level GeoTools/OpenGis objects
>>> (FeatureType, Feature).
>>>
>>> GIS applications, in my opinion, generally don't need to know what type of
>>> data source they are using. This is one advantage of using a toolkit like
>>> GeoTools. You could open a wide selection of GIS datasources, and hadle them
>>> the same way. So why would anyone need direct access to the low level GPX
>>> objects?
>>>
>>> Anyways, I don't say that my implementation of the low level part is the
>>> only/best way to do it, but I don't see the point in the design
>>> considerations and modifications you made.
>>>
>>> Peter
>>>
>>> Sunburned Surveyor wrote:
>>>
>>>> You can find my experimental GPX code here:
>>>>
>>>> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/gpx/src/
>>>>
>>>> The code is documented or unit tested yet, and some of the methods are
>>>> stubs. I'm fooling around with some techniques for accessing and
>>>> managing GPX that are a little different from the ones Peter chose.
>>>> Some of these differences are listed below:
>>>>
>>>> - My initial reader and writer will be based on JDOM.
>>>> - I'll be supporting the extensions element via the JDOM Element object.
>>>> - I'll be supporting the time element via the Joda DateTime element.
>>>> - I'm using "user friendly" names like getRoute instead of getRte, or
>>>> getWaypoint instead of getWpt.
>>>> - I'll be providing low-level access to the entities stored in a GPX
>>>> file. This means you could use this code to convert a GPX file into a
>>>> DXF file or SVG file without dealing with any Feature object, for
>>>> example. Another example is the ability to get at the raw double
>>>> values representing the ordinates of the GPX file bounding box without
>>>> dealing with an Envelope class from GeoTools. (This access will be
>>>> provided at a higher level for GeoTools clients.)
>>>> - I'll be providing access to GPX entities as DataObjects. This access
>>>> will be provided one level "below" the access that I will provide to
>>>> GPX entities as implementations of org.geotools.feature.SimpleFeature.
>>>> This will allow programs like OpenJUMP to access GPX files without the
>>>> need to deal with the GeoTools feature model.
>>>> - I'll be supporting access to a representation to GPX files as some
>>>> sort of GeoFileResource class. This will allow client code to query a
>>>> directory containing GPX files for all the GPX files by the same
>>>> author, after a certain date, or within a particular envelope.
>>>>
>>>> All of these ideas are very preliminary, but I thought I would throw
>>>> them out for discussion. I'm sure Peter will have some comments. My
>>>> main challenge will be implementing the higher level of the library,
>>>> in which I will need to allow access to a SimpleFeature implementation
>>>> in the "GeoTools way" (likely trough a DataStore).
>>>>
>>>> Landon
>>>>
>>>> P.S. - I was looking for a DataStore implementation in Peter's code,
>>>> but didn't see it in the Javadoc for the three GPX packages. Is it
>>>> related to the org.geotools.gpx.bean.ObjectFactory class?
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Geotools-devel mailing list
>>>> Geo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Geotools-devel mailing list
>>> Geo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>