geotools-devel

[Geotools-devel] We want to help

[Ahmed Al-O. <ah...@wa...>]

Hi,
I’m very interesting in adopting geotools, geoserver
and uDig as the standard platform to build GIS
application in the company I work for.

We have an expert team who already has built a very
sophisticated application including rendering MrSID &
GeoTiff format, VRML, and AVL (Automatic Vehicle
Location).
The problem is we use a C++, and now considering
migrating to Java wagon.

So, please let us know if we can help you in any field
that is urgently demanded by the GIS applications.

Ahmad

Re: [Geotools-devel] We want to help

[Chris H. <ch...@op...>]

> Hi,
> I=92m very interesting in adopting geotools, geoserver
> and uDig as the standard platform to build GIS
> application in the company I work for.
Great!

> We have an expert team who already has built a very
> sophisticated application including rendering MrSID &
> GeoTiff format, VRML, and AVL (Automatic Vehicle
> Location).
> The problem is we use a C++, and now considering
> migrating to Java wagon.

> So, please let us know if we can help you in any field
> that is urgently demanded by the GIS applications.
Well, there are always tons of places to help out.  But the key is to
find an area that is useful to _you_.  There are many, many tasks that
we can just assign you, but you will not be motivated to do them unless
they actually generate something that benefits you.  So I would say the
best thing to do would be to start to try out udig/geoserver/geotools
as a platform, with some sort of pilot project.  Maybe just trying to
port part of your current application over.  Doing so will probably
show the places where the open source stuff is lacking, things you were
expecting it to do, but that it didn't.  When that happens (and it
will) talk to us, and we probably will have thought about it, and have
notions about how to do it right.  Then you can submit patches, and
eventually get commit rights and move fully into the open source
community.  We strive to be as open of a community as possible.  But
you should focus your work around things that you want done, that will
benefit you and your company directly, or else it's not too likely your
contributions will be sustainable - we really want people to become a
part of this all.

If you do want a good concrete task that might be a good place to start,
one idea is to look into getting OGR and GDAL working with GeoTools.=20
These are two amazing open source libraries, written in C, that support
a very large number of formats.  OGR is vector, and GDAL raster.=20
GeoTools reads vectors with a DataStore construct =96 it should not be
all that hard to make a OGRDataStore, with JNI, that will leverage the
C libraries.  This would be a great contribution, as it would allow
GeoTools to support many, many more formats.  GDAL is similar, but
would go into the GridCoverage API.  It would be an even bigger win,
since GeoTools raster support is only beginning, and what the GDAL guys
have done is amazing.  This would leverage your C++ knowledge, and
perhaps also show how you might be able to integrate some of your
existing work with geotools.

Hope this helps,

Chris

Quoting Ahmed Al-Obaidy <ah...@wa...>:

> Hi,
> I=92m very interesting in adopting geotools, geoserver
> and uDig as the standard platform to build GIS
> application in the company I work for.
>
> We have an expert team who already has built a very
> sophisticated application including rendering MrSID &
> GeoTiff format, VRML, and AVL (Automatic Vehicle
> Location).
> The problem is we use a C++, and now considering
> migrating to Java wagon.
>
> So, please let us know if we can help you in any field
> that is urgently demanded by the GIS applications.
>
> Ahmad
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Geotools-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

Re: [Geotools-devel] We want to help

[James M. <jma...@gm...>]

>=20
> If you do want a good concrete task that might be a good place to start,
> one idea is to look into getting OGR and GDAL working with GeoTools.
> These are two amazing open source libraries, written in C, that support
> a very large number of formats.=20

Specificaly, there are two JIRA tasks related to these (ok, so I just
created the second one)
http://jira.codehaus.org/browse/GEOT-155
http://jira.codehaus.org/browse/GEOT-500

You might also be interested in implementing a GPS DataStore given
your experience in that area:
http://jira.codehaus.org/browse/GEOT-104

James

Re: [Geotools-devel] We want to help

[Ahmed Al-O. <ah...@wa...>]

--- James Macgill <jma...@gm...> wrote:

> > 
> > If you do want a good concrete task that might be
> a good place to start,
> > one idea is to look into getting OGR and GDAL
> working with GeoTools.
> > These are two amazing open source libraries,
> written in C, that support
> > a very large number of formats. 
> 
> Specificaly, there are two JIRA tasks related to
> these (ok, so I just
> created the second one)
> http://jira.codehaus.org/browse/GEOT-155
> http://jira.codehaus.org/browse/GEOT-500
> 
> You might also be interested in implementing a GPS
> DataStore given
> your experience in that area:
> http://jira.codehaus.org/browse/GEOT-104
> 
> James
> 

Re: [Geotools-devel] We want to help

[Ahmed Al-O. <ah...@wa...>]

I would prefer to cleanly port the code to pure Java
than wrapping the C code using JNI.
That would keep the portability of the GeoTools, which
is one of the most attractive features in GeoTools( at
least we think so).

Implementing a GPS DataStore is a good task to be
assigned to us... so as implementing GridCoverage for
MrSID format…

But you have to give us a time to get familiar with
Java/Open source community. 

Best Regards,
Ahmad

--- James Macgill <jma...@gm...> wrote:

> > 
> > If you do want a good concrete task that might be
> a good place to start,
> > one idea is to look into getting OGR and GDAL
> working with GeoTools.
> > These are two amazing open source libraries,
> written in C, that support
> > a very large number of formats. 
> 
> Specificaly, there are two JIRA tasks related to
> these (ok, so I just
> created the second one)
> http://jira.codehaus.org/browse/GEOT-155
> http://jira.codehaus.org/browse/GEOT-500
> 
> You might also be interested in implementing a GPS
> DataStore given
> your experience in that area:
> http://jira.codehaus.org/browse/GEOT-104
> 
> James
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
> _______________________________________________
> Geotools-devel mailing list
> Geo...@li...
>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 

Re: [Geotools-devel] We want to help

[Craig B. <cb...@bi...>]

Has much been done with regards to GDAL/OGR wrappers?  I remember some 
one on the GDAL mailing list was also developing java wrappers for GDAL.

I do have some wrappers for java which I implemented last year for OGR 
(enough to play around with TAB files.)  Rough as guts but I should dig 
them out and attach them to the JIRA task.  Haven't done much with GDAL 
though.

Cheers,

---
Craig Byrne
MapGenix, Brisbane, Australia
http://www.mapgenix.com.au/


James Macgill wrote:

>>If you do want a good concrete task that might be a good place to start,
>>one idea is to look into getting OGR and GDAL working with GeoTools.
>>These are two amazing open source libraries, written in C, that support
>>a very large number of formats. 
>>    
>>
>
>Specificaly, there are two JIRA tasks related to these (ok, so I just
>created the second one)
>http://jira.codehaus.org/browse/GEOT-155
>http://jira.codehaus.org/browse/GEOT-500
>
>You might also be interested in implementing a GPS DataStore given
>your experience in that area:
>http://jira.codehaus.org/browse/GEOT-104
>
>James
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Geotools-devel mailing list
>Geo...@li...
>https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>  
>

Re: [Geotools-devel] We want to help

[Martin D. <mar...@no...>]

Ahmed Al-Obaidy a =E9crit :
> So, please let us know if we can help you in any field
> that is urgently demanded by the GIS applications.

There is a field that seems urgent to me, but it is a little bit tedious=20
(something really important, but not impressive to show):

   - Write a tool for comparing GeoAPI interfaces against OGC's UML.

Steps to understand what I mean:

1) Geotools is (partially) an implementation of GeoAPI interfaces
    (http://geoapi.sourceforge.net).

2) GeoAPI is a translation of OpenGIS Consortium specifications
    (http://www.opengis.org) from UML to Java interfaces.

3) OpenGIS's UML are derived from ISO 211 working group. Their
    UML models are available there:

    http://www.isotc211.org/HMMG/Model2005-03-17/


Up to now, step #2 was done by hand because there is not always a 1-to-1=20
relationship between UML and Java interfaces. But each Java interface or=20
method has an annotation saying from which UML entity it come from. We=20
need a Java tools inspecting Java interfaces through reflection, and=20
comparing against ISO 211 UML model. Non-documented mismatches must be=20
fixed before there is too much dependencies on top of GeoAPI interfaces.

	Martin.

RE: [Geotools-devel] We want to help

[Paul S. <pa...@to...>]

> 3) OpenGIS's UML are derived from ISO 211 working group. Their
>     UML models are available there:
> 
>     http://www.isotc211.org/HMMG/Model2005-03-17/

This may be off-topic. Any free way to view the OpenGIS's UML models?

I do not have the Rational Rose and it is currently not on my budget.

Best regards,
Paul. 

Re: [Geotools-devel] We want to help

[Jody G. <jga...@re...>]

Paul Selormey wrote:

>>3) OpenGIS's UML are derived from ISO 211 working group. Their
>>    UML models are available there:
>>
>>    http://www.isotc211.org/HMMG/Model2005-03-17/
>>    
>>
>
>This may be off-topic. Any free way to view the OpenGIS's UML models?
>  
>
Grab GeoAPI and Omondo and generate a diagram :-)

Seriously GeoAPI is often better then the UML Models in that an 
implementation is often available. Occasionally (GML3 cough) OGC goes
model happy and makes things that don't actually work.

Omonodo is a free download (for non "team" projects - so shut off 
subclicpse) and is highly recommended.

Jody.