Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread Sunburned Surveyor
It looks like there is some interest and opportunity for collaboration
with the GeoTools team on FGDB support. You can see the thread I
started on their development mailing list here:

http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html

I'm already way over committed, so I can't take the lead on this
effort, but I hope we can work together with the GeoTools people if
there is a desire and resources for work on a FGDB library.

Landon

On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
sunburned.surve...@gmail.com wrote:
 If we did decide to explore FGDB support for OpenJUMP, I'd recommend
 we collaborate with GeoTools on the lower-level code. I can post there
 to see if there is anything going on in this area and will get back to
 the list.

 Landon

 On Thu, Aug 4, 2011 at 2:25 AM,  edgar.sol...@web.de wrote:
 Thanks for the overview on this.. ede

 On 04.08.2011 01:28, Martin Davis wrote:
 Yes, they are definitely positioning FGDBs as the replacement for 
 shapefiles - at least in their world.  FGDB has a lot of advantages for 
 them - no limit on file size, able to contain all of the weird and 
 wonderful ESRI data structures, and platform-independent.  Oh, and no 
 11-char limit on field names!!!

 philosophy
 Personally I can't see it replacing the role that Shapefiles play in the 
 wider geospatial world - that is, a (fairly( open, easily-accessible, 
 documented spatial data format.  The FGDB format is closed and proprietary 
 - only the API is somewhat open.  And it's written in C, which limits its 
 use in some situations.  Also, the FGDB format is very complex, and 
 completely tailored to support ESRI's needs, rather than a more general set 
 of needs.

 It would be GREAT to have a truly open geospatial format, which was 
 essentially a shapefile for the 21st century.  GML is NOT that format...  
 so the field lies open
 /philosophy

 It would be great to have a solution for accessing FGDBs from Java 
 (OpenJUMP of course, but I'd also like to be able to read them from JEQL).  
 If OJ could read them that should make it quite appealing for working with 
 newer ESRI data.

 One possiblity is this work on a Java interface to the FGDB API.  If this 
 project has taken care of all the JNI nastiness, then it could be worth 
 using.

 http://sourceforge.net/projects/jfilegdbexplore/ 
 http://sourceforge.net/projects/jfilegdbexplore/

 I know that the GDAL project is working on adding a driver for the FGDB 
 API.  This is in C, of course, so not directly usable by OJ.

 Martin

 On 8/3/2011 8:27 AM, Larry Becker wrote:
 It would seem that ESRI is positioning the file geodatabase as the heir 
 to the shapefile.  They now have a cross-platform API that provides access 
 without ArcObjects.

 http://forums.arcgis.com/threads/31841-Welcome-to-the-discussion-forum-for-the-File-Geodatabase-API!

 Is this something the JUMP community should look into supporting?

 Larry



 --
 BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
 The must-attend event for mobile developers. Connect with experts.
 Get tools for creating Super Apps. See the latest technologies.
 Sessions, hands-on labs, demos  much more. Register early  save!
 http://p.sf.net/sfu/rim-blackberry-1
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread edgar . soldin
Obviously there is interest in geotools to add a gt2 datastore for it. Also 
cite:

Justin Deoliveira: Just a note that fgdb support was recently added to ogr as 
a format... so using the existing ogr datastore (and its java bindings for 
ogr) could be an easier route to go. However it requires ogr = 1.9.0. 

In any way we should (re)implement a geotools reader/writer extension or pimp 
my old GT2 reader/writer to work with the latest oj.

ede


On 08.08.2011 17:07, Sunburned Surveyor wrote:
 It looks like there is some interest and opportunity for collaboration
 with the GeoTools team on FGDB support. You can see the thread I
 started on their development mailing list here:
 
 http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html
 
 I'm already way over committed, so I can't take the lead on this
 effort, but I hope we can work together with the GeoTools people if
 there is a desire and resources for work on a FGDB library.
 
 Landon
 
 On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
 sunburned.surve...@gmail.com wrote:
 If we did decide to explore FGDB support for OpenJUMP, I'd recommend
 we collaborate with GeoTools on the lower-level code. I can post there
 to see if there is anything going on in this area and will get back to
 the list.

 Landon

 On Thu, Aug 4, 2011 at 2:25 AM,  edgar.sol...@web.de wrote:
 Thanks for the overview on this.. ede

 On 04.08.2011 01:28, Martin Davis wrote:
 Yes, they are definitely positioning FGDBs as the replacement for 
 shapefiles - at least in their world.  FGDB has a lot of advantages for 
 them - no limit on file size, able to contain all of the weird and 
 wonderful ESRI data structures, and platform-independent.  Oh, and no 
 11-char limit on field names!!!

 philosophy
 Personally I can't see it replacing the role that Shapefiles play in the 
 wider geospatial world - that is, a (fairly( open, easily-accessible, 
 documented spatial data format.  The FGDB format is closed and proprietary 
 - only the API is somewhat open.  And it's written in C, which limits its 
 use in some situations.  Also, the FGDB format is very complex, and 
 completely tailored to support ESRI's needs, rather than a more general 
 set of needs.

 It would be GREAT to have a truly open geospatial format, which was 
 essentially a shapefile for the 21st century.  GML is NOT that format...  
 so the field lies open
 /philosophy

 It would be great to have a solution for accessing FGDBs from Java 
 (OpenJUMP of course, but I'd also like to be able to read them from JEQL). 
  If OJ could read them that should make it quite appealing for working 
 with newer ESRI data.

 One possiblity is this work on a Java interface to the FGDB API.  If this 
 project has taken care of all the JNI nastiness, then it could be worth 
 using.

 http://sourceforge.net/projects/jfilegdbexplore/ 
 http://sourceforge.net/projects/jfilegdbexplore/

 I know that the GDAL project is working on adding a driver for the FGDB 
 API.  This is in C, of course, so not directly usable by OJ.

 Martin

 On 8/3/2011 8:27 AM, Larry Becker wrote:
 It would seem that ESRI is positioning the file geodatabase as the heir 
 to the shapefile.  They now have a cross-platform API that provides 
 access without ArcObjects.

 http://forums.arcgis.com/threads/31841-Welcome-to-the-discussion-forum-for-the-File-Geodatabase-API!

 Is this something the JUMP community should look into supporting?

 Larry



 --
 BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
 The must-attend event for mobile developers. Connect with experts.
 Get tools for creating Super Apps. See the latest technologies.
 Sessions, hands-on labs, demos  much more. Register early  save!
 http://p.sf.net/sfu/rim-blackberry-1
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


 
 --
 BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
 The must-attend event for mobile developers. Connect with experts. 
 Get tools for creating Super Apps. See the latest technologies.
 Sessions, hands-on labs, demos  much more. Register early  save!
 http://p.sf.net/sfu/rim-blackberry-1
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1

[JPP-Devel] Reg Shortest Path finder in OpenJUMP

2011-08-08 Thread Harshad Shrikhande
Hey folks,

  Does anyone know how to find the shortest path between 2 nodes on
a map in OpenJUMP. Is there any plugin that does this. The data is stored in
PostGIS.

Thank You.
Harshad Shrikhande
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Reg Shortest Path finder in OpenJUMP

2011-08-08 Thread Stefan Steiniger

Hei,

not sure - there have been some attempts but i don't know the latest state.
here is a graph toolbox for OJ
http://sourceforge.net/projects/jump-pilot/files/p_%20More%20Plugins/

and then Mohammed Rashad worked ona a PgRoutingPlugIn (unfortunately the 
SVN folders for that are empty???)

http://groups.google.com/group/openjump-users/browse_thread/thread/67916c09bce5db4c
or better:
http://lsi.iiit.ac.in/openjump-plugins/

can you give it a try?

stefan

On 08/08/2011 9:42 AM, Harshad Shrikhande wrote:

Hey folks,

  Does anyone know how to find the shortest path between 2 
nodes on a map in OpenJUMP. Is there any plugin that does this. The 
data is stored in PostGIS.


Thank You.
Harshad Shrikhande


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] Reg Shortest Path finder in OpenJUMP

2011-08-08 Thread Stefan Steiniger
oh.. I just see too, that we have the pgRouting plugin on our server, 
but in the database plugin section:

http://sourceforge.net/projects/jump-pilot/files/p_database_plugins/

sorry for that
stefan

On 08/08/2011 10:40 AM, Stefan Steiniger wrote:

Hei,

not sure - there have been some attempts but i don't know the latest 
state.

here is a graph toolbox for OJ
http://sourceforge.net/projects/jump-pilot/files/p_%20More%20Plugins/

and then Mohammed Rashad worked ona a PgRoutingPlugIn (unfortunately 
the SVN folders for that are empty???)

http://groups.google.com/group/openjump-users/browse_thread/thread/67916c09bce5db4c
or better:
http://lsi.iiit.ac.in/openjump-plugins/

can you give it a try?

stefan

On 08/08/2011 9:42 AM, Harshad Shrikhande wrote:

Hey folks,

  Does anyone know how to find the shortest path between 2 
nodes on a map in OpenJUMP. Is there any plugin that does this. The 
data is stored in PostGIS.


Thank You.
Harshad Shrikhande


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel




--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread Larry Becker
It looks like there could be cooperation between the two groups on the
development of the Java interface at least.

The following thread is a bit discouraging toward that effort:
http://forums.arcgis.com/threads/35051-Problem-loading-libraries-to-Java

The sourceforge project at
http://sourceforge.net/projects/jfilegdbexplore/looks very thin, but
seems to imply it can be done.

The post at
http://forums.arcgis.com/threads/2696-How-To-File-Geodatabase-using-Java is
listed under the ArcObjects forum, and not the forum dedicated to the new
API.

The ogr support approach would not seem to provide any advantage beyond
translating FGDB to shapefiles as SkyJUMP uses that library for mdb
translation now.  There may be Java bindings for the low level API in OGR
that I'm not aware of, but this would be a level removed from the actual API
we want to use.

The only way this would be any use in JUMP (IMHO) is if we could open and
edit FGDBs like ArcMap does.  We discussed the idea of supporting the Access
personal geodatabase years ago, but abandoned the idea because it was too
risky because it was proprietary and had no published API.

As far as the ESRI license, it would put us in the same position as having
the end user download the MRSID executable.  Not good, but doable.

On the minus side, by supporting the proprietary FGDB format, we might be
using effort that could be better applied to open source solutions.

What are the viable open source alternatives?  Spatial Lite seems to have a
C API as well.

just a few thoughts,

Larry




On Mon, Aug 8, 2011 at 10:22 AM, edgar.sol...@web.de wrote:

 Obviously there is interest in geotools to add a gt2 datastore for it. Also
 cite:

 Justin Deoliveira: Just a note that fgdb support was recently added to ogr
 as a format... so using the existing ogr datastore (and its java bindings
 for ogr) could be an easier route to go. However it requires ogr = 1.9.0.

 In any way we should (re)implement a geotools reader/writer extension or
 pimp my old GT2 reader/writer to work with the latest oj.

 ede


 On 08.08.2011 17:07, Sunburned Surveyor wrote:
  It looks like there is some interest and opportunity for collaboration
  with the GeoTools team on FGDB support. You can see the thread I
  started on their development mailing list here:
 
 
 http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html
 
  I'm already way over committed, so I can't take the lead on this
  effort, but I hope we can work together with the GeoTools people if
  there is a desire and resources for work on a FGDB library.
 
  Landon
 
  On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
  sunburned.surve...@gmail.com wrote:
  If we did decide to explore FGDB support for OpenJUMP, I'd recommend
  we collaborate with GeoTools on the lower-level code. I can post there
  to see if there is anything going on in this area and will get back to
  the list.
 
  Landon
 
  On Thu, Aug 4, 2011 at 2:25 AM,  edgar.sol...@web.de wrote:
  Thanks for the overview on this.. ede
 
  On 04.08.2011 01:28, Martin Davis wrote:
  Yes, they are definitely positioning FGDBs as the replacement for
 shapefiles - at least in their world.  FGDB has a lot of advantages for them
 - no limit on file size, able to contain all of the weird and wonderful ESRI
 data structures, and platform-independent.  Oh, and no 11-char limit on
 field names!!!
 
  philosophy
  Personally I can't see it replacing the role that Shapefiles play in
 the wider geospatial world - that is, a (fairly( open, easily-accessible,
 documented spatial data format.  The FGDB format is closed and proprietary -
 only the API is somewhat open.  And it's written in C, which limits its use
 in some situations.  Also, the FGDB format is very complex, and completely
 tailored to support ESRI's needs, rather than a more general set of needs.
 
  It would be GREAT to have a truly open geospatial format, which was
 essentially a shapefile for the 21st century.  GML is NOT that format...  so
 the field lies open
  /philosophy
 
  It would be great to have a solution for accessing FGDBs from Java
 (OpenJUMP of course, but I'd also like to be able to read them from JEQL).
  If OJ could read them that should make it quite appealing for working with
 newer ESRI data.
 
  One possiblity is this work on a Java interface to the FGDB API.  If
 this project has taken care of all the JNI nastiness, then it could be worth
 using.
 
  http://sourceforge.net/projects/jfilegdbexplore/ 
 http://sourceforge.net/projects/jfilegdbexplore/
 
  I know that the GDAL project is working on adding a driver for the
 FGDB API.  This is in C, of course, so not directly usable by OJ.
 
  Martin
 
  On 8/3/2011 8:27 AM, Larry Becker wrote:
  It would seem that ESRI is positioning the file geodatabase as the
 heir to the shapefile.  They now have a cross-platform API that provides
 access without ArcObjects.
 
 
 

Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread edgar . soldin
On 08.08.2011 19:33, Larry Becker wrote:
 It looks like there could be cooperation between the two groups on the 
 development of the Java interface at least. 
 
 The following thread is a bit discouraging toward that effort: 
 http://forums.arcgis.com/threads/35051-Problem-loading-libraries-to-Java

i have some experience with rxtx serial library in this regard and even wrote 
an autoload the correct library for the os we are running on wrapper. so when 
push comes to shove i can deliver support there.
 
 
 The ogr support approach would not seem to provide any advantage beyond 
 translating FGDB to shapefiles as SkyJUMP uses that library for mdb 
 translation now.  There may be Java bindings for the low level API in OGR 
 that I'm not aware of, but this would be a level removed from the actual API 
 we want to use.

why would it be removed?

i still like the idea of having an interface that uses geotools mechanisms to 
load data. that would automatically enable oj users to use all gt2 datastores. 
opinions?

 The only way this would be any use in JUMP (IMHO) is if we could open and 
 edit FGDBs like ArcMap does.  We discussed the idea of supporting the Access 
 personal geodatabase years ago, but abandoned the idea because it was too 
 risky because it was proprietary and had no published API.

good point. the licensing terms of ESRI are pretty discouraging as far as i 
understand.

 As far as the ESRI license, it would put us in the same position as having 
 the end user download the MRSID executable.  Not good, but doable.

agreed

 
 On the minus side, by supporting the proprietary FGDB format, we might be 
 using effort that could be better applied to open source solutions.
 
 What are the viable open source alternatives?  Spatial Lite seems to have a C 
 API as well.
 

also agreed. as long as it is not really open, as in free software, i am in no 
way interested to take part in developing for a company that does not even pay 
me (respect).

still i am open to use solution others came up with, using the c api or 
whatever, or help out if i can (see loading native libraries above).  regards 
ede


 
 On Mon, Aug 8, 2011 at 10:22 AM, edgar.sol...@web.de 
 mailto:edgar.sol...@web.de wrote:
 
 Obviously there is interest in geotools to add a gt2 datastore for it. 
 Also cite:
 
 Justin Deoliveira: Just a note that fgdb support was recently added to 
 ogr as a format... so using the existing ogr datastore (and its java bindings 
 for ogr) could be an easier route to go. However it requires ogr = 1.9.0.
 
 In any way we should (re)implement a geotools reader/writer extension or 
 pimp my old GT2 reader/writer to work with the latest oj.
 
 ede
 
 
 On 08.08.2011 17:07, Sunburned Surveyor wrote:
  It looks like there is some interest and opportunity for collaboration
  with the GeoTools team on FGDB support. You can see the thread I
  started on their development mailing list here:
 
  
 http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html
 
  I'm already way over committed, so I can't take the lead on this
  effort, but I hope we can work together with the GeoTools people if
  there is a desire and resources for work on a FGDB library.
 
  Landon
 
  On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
  sunburned.surve...@gmail.com mailto:sunburned.surve...@gmail.com 
 wrote:
  If we did decide to explore FGDB support for OpenJUMP, I'd recommend
  we collaborate with GeoTools on the lower-level code. I can post there
  to see if there is anything going on in this area and will get back to
  the list.
 
  Landon
 
  On Thu, Aug 4, 2011 at 2:25 AM,  edgar.sol...@web.de 
 mailto:edgar.sol...@web.de wrote:
  Thanks for the overview on this.. ede
 
  On 04.08.2011 01:28, Martin Davis wrote:
  Yes, they are definitely positioning FGDBs as the replacement for 
 shapefiles - at least in their world.  FGDB has a lot of advantages for them 
 - no limit on file size, able to contain all of the weird and wonderful ESRI 
 data structures, and platform-independent.  Oh, and no 11-char limit on field 
 names!!!
 
  philosophy
  Personally I can't see it replacing the role that Shapefiles play in 
 the wider geospatial world - that is, a (fairly( open, easily-accessible, 
 documented spatial data format.  The FGDB format is closed and proprietary - 
 only the API is somewhat open.  And it's written in C, which limits its use 
 in some situations.  Also, the FGDB format is very complex, and completely 
 tailored to support ESRI's needs, rather than a more general set of needs.
 
  It would be GREAT to have a truly open geospatial format, which was 
 essentially a shapefile for the 21st century.  GML is NOT that format...  so 
 the field lies open
  /philosophy
 
  It would be great to have a solution for accessing FGDBs from Java 
 (OpenJUMP 

Re: [JPP-Devel] some admin stuff and questions to all

2011-08-08 Thread edgar . soldin
On 08.08.2011 19:07, Stefan Steiniger wrote:
 Hei Guys,
 
 here two things with request for your opinions:
 a - I noticed that Sourceforge offers now Wordpress for blog writing. I 
 requested activation of this feature. Hence we can start writing blog entries 
 on OpenJUMP such as  small tutorial, tips  tricks, and maybe new version 
 releases... but I am not sure about the latter. I have been waiting for this

while it's not very beautiful i am satisfied with the wiki. we are already 
pretty much spread over several platforms namely website, wiki, mailing list 
and not to name the forums and trackers on sf.net.
a new cms would only contribute to this scattering. the wiki is already 
outdated in some areas and i'd rather see it updated than to start a fresh with 
a new cms.

btw. don't expect to much from sf.net wordpress. last time i checked you were 
not even able to change the theme. what are your reasons to fancy wordpress? 
i'd see a possibility to convert the website over to wordpress, adopting the 
style and such. but therefor we'd have to install ourselves a wordpress. i 
could lend some webspace for that, as i think th sf.net webspace would not 
suffice, but i could be wrong.

so as a website replacement i think it is a good idea.

 
 b - I also noticed that via Sourceforge and creation of PayPal account we can 
 activate a donate-Button on SourceForge. All Admins (Landon, Ede, Michael  
 I need to approve the feature on SF before it can be activated.) I guess we 
 should all read more about it first:
 http://sourceforge.net/project/admin/donations.php?group_id=118054
 But I like to have know how you think about donations via SF or more 
 precisely: should we look into it or keep things as is. I am actually asking 
 here all on the email list who have an opinion about that.

is there a possibility to share paypal accounts, so several people would have 
access and could control each other? generally i am in favor, we should at ave 
the possibility for people to donate. if nobody donates, then at least it's not 
because there is no possibility.

 
 PS: we still have these incredible download rates (2000 a month for OJ 
 itself) - see the attached pdf. But I am not sure why people would download a 
 lot on Monday... doesn't make sense to me. Btw. one can also see that for 4th 
 of July (national US holiday) the download rate was a bit lower.
 
 

maybe we should setup a hello there, please tell us what you think of 
openjump in oj that pops up after the first start or first 30 days. we could 
route users from there to a page where they could input a message or even hints 
what could be better. currently we have no f*** clue who is using us, except 
that we are used, i guess ;)

..ede


--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread Rahkonen Jukka
Hi


 Larry Becker  wrote:

 What are the viable open source alternatives?  Spatial Lite seems to have a C 
 API as well.

We have two examples about, unfortunately, read-only access to Spatialite with 
OpenJUMP. Both work well but I do not know if they are viable. See 
http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite

-Jukka Rahkonen-
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos  much more. Register early  save!
http://p.sf.net/sfu/rim-blackberry-1___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread Larry Becker
Hi ede,

why would it be removed?

I was referring to the OGR API adding a level of abstraction above the
actual FGDB C++ API, but still being not a Java API.

i still like the idea of having an interface that uses geotools mechanisms
to load data. that would automatically enable oj users to use all gt2
datastores. opinions?

I like using geotools too.  If they implement a FGDB datastore that has read
and write access, it should be the preferred method.

Larry

On Mon, Aug 8, 2011 at 1:52 PM, edgar.sol...@web.de wrote:

 On 08.08.2011 19:33, Larry Becker wrote:
  It looks like there could be cooperation between the two groups on the
 development of the Java interface at least.
 
  The following thread is a bit discouraging toward that effort:
 http://forums.arcgis.com/threads/35051-Problem-loading-libraries-to-Java

 i have some experience with rxtx serial library in this regard and even
 wrote an autoload the correct library for the os we are running on wrapper.
 so when push comes to shove i can deliver support there.

 
  The ogr support approach would not seem to provide any advantage beyond
 translating FGDB to shapefiles as SkyJUMP uses that library for mdb
 translation now.  There may be Java bindings for the low level API in OGR
 that I'm not aware of, but this would be a level removed from the actual API
 we want to use.

 why would it be removed?

 i still like the idea of having an interface that uses geotools mechanisms
 to load data. that would automatically enable oj users to use all gt2
 datastores. opinions?

  The only way this would be any use in JUMP (IMHO) is if we could open and
 edit FGDBs like ArcMap does.  We discussed the idea of supporting the Access
 personal geodatabase years ago, but abandoned the idea because it was too
 risky because it was proprietary and had no published API.

 good point. the licensing terms of ESRI are pretty discouraging as far as i
 understand.

  As far as the ESRI license, it would put us in the same position as
 having the end user download the MRSID executable.  Not good, but doable.

 agreed

 
  On the minus side, by supporting the proprietary FGDB format, we might be
 using effort that could be better applied to open source solutions.
 
  What are the viable open source alternatives?  Spatial Lite seems to have
 a C API as well.
 

 also agreed. as long as it is not really open, as in free software, i am in
 no way interested to take part in developing for a company that does not
 even pay me (respect).

 still i am open to use solution others came up with, using the c api or
 whatever, or help out if i can (see loading native libraries above).
  regards ede


 
  On Mon, Aug 8, 2011 at 10:22 AM, edgar.sol...@web.de mailto:
 edgar.sol...@web.de wrote:
 
  Obviously there is interest in geotools to add a gt2 datastore for
 it. Also cite:
 
  Justin Deoliveira: Just a note that fgdb support was recently added
 to ogr as a format... so using the existing ogr datastore (and its java
 bindings for ogr) could be an easier route to go. However it requires ogr =
 1.9.0.
 
  In any way we should (re)implement a geotools reader/writer extension
 or pimp my old GT2 reader/writer to work with the latest oj.
 
  ede
 
 
  On 08.08.2011 17:07, Sunburned Surveyor wrote:
   It looks like there is some interest and opportunity for
 collaboration
   with the GeoTools team on FGDB support. You can see the thread I
   started on their development mailing list here:
  
  
 http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html
  
   I'm already way over committed, so I can't take the lead on this
   effort, but I hope we can work together with the GeoTools people if
   there is a desire and resources for work on a FGDB library.
  
   Landon
  
   On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
   sunburned.surve...@gmail.com mailto:sunburned.surve...@gmail.com
 wrote:
   If we did decide to explore FGDB support for OpenJUMP, I'd
 recommend
   we collaborate with GeoTools on the lower-level code. I can post
 there
   to see if there is anything going on in this area and will get
 back to
   the list.
  
   Landon
  
   On Thu, Aug 4, 2011 at 2:25 AM,  edgar.sol...@web.de mailto:
 edgar.sol...@web.de wrote:
   Thanks for the overview on this.. ede
  
   On 04.08.2011 01:28, Martin Davis wrote:
   Yes, they are definitely positioning FGDBs as the replacement
 for shapefiles - at least in their world.  FGDB has a lot of advantages for
 them - no limit on file size, able to contain all of the weird and wonderful
 ESRI data structures, and platform-independent.  Oh, and no 11-char limit on
 field names!!!
  
   philosophy
   Personally I can't see it replacing the role that Shapefiles
 play in the wider geospatial world - that is, a (fairly( open,
 easily-accessible, documented spatial data format.  The FGDB 

Re: [JPP-Devel] ESRI file geodatabases

2011-08-08 Thread Martin Davis



On 8/8/2011 10:33 AM, Larry Becker wrote:
It looks like there could be cooperation between the two groups on the 
development of the Java interface at least.

Cooperation with GeoTools seems like a reasonable way to go.


The ogr support approach would not seem to provide any advantage 
beyond translating FGDB to shapefiles as SkyJUMP uses that library for 
mdb translation now.  There may be Java bindings for the low level API 
in OGR that I'm not aware of, but this would be a level removed from 
the actual API we want to use.
Agreed.  It's bad enough having to include the C libs needed for access 
to non-Java APIs, but including a bunch of OGR libs as well just 
compounds the problem.


Also, from a development point-of-view if there are issues that makes 
two places which need to be looked at and updated - and if the problem 
is in OGR then OJ is hostage to OGR's schedule.


The only way this would be any use in JUMP (IMHO) is if we could open 
and edit FGDBs like ArcMap does.  We discussed the idea of supporting 
the Access personal geodatabase years ago, but abandoned the idea 
because it was too risky because it was proprietary and had no 
published API.


Disagreed.  Providing Read-Only access to FGDB is still very useful, 
since it provides a gateway into OJ for ESRI users.  And there is lots 
of functionality which is difficult to accomplish in ESRI tools which is 
easy in OJ (and other Java solutions like JEQL). I'm now in the 
unenviable position of working with ESRI tools on a daily basis, and by 
the biggest stumbling block to trying to introduce OJ into my 
environment is the inability to read the (sometimes huge) FGDBs that we use.


Another way to think of this - what better way to to suck the life out 
of a proprietary format than to make a one-way gateway into an open 
solution?  (This is a tried-and-true ploy of proprietary platforms...)


I'm not even sure that the ESRI FGDB API supports writing.. or at least, 
not without a lot of caveats.


As far as the ESRI license, it would put us in the same position as 
having the end user download the MRSID executable.  Not good, but doable.


On the minus side, by supporting the proprietary FGDB format, we might 
be using effort that could be better applied to open source solutions.

See comment above about providing a gateway...


What are the viable open source alternatives?  Spatial Lite seems to 
have a C API as well.
SpatialLite support would be useful too, but I don't think it's going to 
replace FGDB in the wider world anytime soon (unfortunately).


just a few thoughts,

Larry




On Mon, Aug 8, 2011 at 10:22 AM, edgar.sol...@web.de 
mailto:edgar.sol...@web.de wrote:


Obviously there is interest in geotools to add a gt2 datastore for
it. Also cite:

Justin Deoliveira: Just a note that fgdb support was recently
added to ogr as a format... so using the existing ogr datastore
(and its java bindings for ogr) could be an easier route to go.
However it requires ogr = 1.9.0.

In any way we should (re)implement a geotools reader/writer
extension or pimp my old GT2 reader/writer to work with the latest oj.

ede


On 08.08.2011 17:07, Sunburned Surveyor wrote:
 It looks like there is some interest and opportunity for
collaboration
 with the GeoTools team on FGDB support. You can see the thread I
 started on their development mailing list here:



http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html

 I'm already way over committed, so I can't take the lead on this
 effort, but I hope we can work together with the GeoTools people if
 there is a desire and resources for work on a FGDB library.

 Landon

 On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor
 sunburned.surve...@gmail.com
mailto:sunburned.surve...@gmail.com wrote:
 If we did decide to explore FGDB support for OpenJUMP, I'd
recommend
 we collaborate with GeoTools on the lower-level code. I can
post there
 to see if there is anything going on in this area and will get
back to
 the list.

 Landon

 On Thu, Aug 4, 2011 at 2:25 AM, edgar.sol...@web.de
mailto:edgar.sol...@web.de wrote:
 Thanks for the overview on this.. ede

 On 04.08.2011 01:28, Martin Davis wrote:
 Yes, they are definitely positioning FGDBs as the replacement
for shapefiles - at least in their world.  FGDB has a lot of
advantages for them - no limit on file size, able to contain all
of the weird and wonderful ESRI data structures, and
platform-independent.  Oh, and no 11-char limit on field names!!!

 philosophy
 Personally I can't see it replacing the role that Shapefiles
play in the wider geospatial world - that is, a (fairly( open,
easily-accessible, documented spatial data format.  The FGDB
format is closed and proprietary - only the API is somewhat open.
 And it's written in