[Geoserver-devel] geometryless

Well, yes, you're right that this isn't the answer I'd hoped for. But
the good news is I need look no further for an answer. I guess for the
time being I'll see about using a separate instance at 1.6 using the
community schemas as documented, and see how that goes.

As far as voices and priorities, I will say that I've been surprised
there isn't more demand for at least the simple case of xy pairs
representing point locations in a non-spatially-enabled database table
... surprised that it isn't a mainstream requirement by now to do what
the "locationsxy" code does. We (state government in New Jersey-USA)
are getting increasing demand for lightweight, simple mashup apps that
combine some particular business data set with a standard pre-rendered
base map. And in many of these cases, the canonical source for the
locations is some table or other in a database that is not managed as
spatial data, but does include location information. Traffic cameras,
park-and-ride lots, geodetic monuments, water wells, etc. We
conceptualized a connector that would respond to a WFS request by
retrieving records (possibly within a BBOX) from a table and delivering
them in GeoJSON to an Open Layers client app. We see it opening up a
huge variety of data t
o being displayed on a map, which will be the first foray into GIS for
many of these agencies.

Unfortunately, I have no resources to offer to help make it happen in
Geoserver. It's a tight time for us. So I will see about making it
work with what's out there.

Thanks for the quick reply.

-Andy

----- Original Message -----
From: Rob Atkinson <robatkinson101@anonymised.com>
Date: Wednesday, September 30, 2009 6:32 pm
Subject: Re: [Geoserver-devel] geometryless

Hi,

dont have the answer you are looking for I expect..

the _plan_ is to replace geometryless by the app-schema functionality.

This can done at the app-schema part - , but is held back by the
broader GML 3 support - we dont have an object model we can map into,
there is a point solution mapping 2D geometry objects into the
bindings. I've been trying to get this relaxed to allow a complete
solution for a while - maybe your voice can help with the priorities.
I cant fix it myself because there is auto-generated code in the loop,
and the autogeneration process is not yet repeatable.

Making it work in 1.7 is feasible, but not as important to me as 2.0
support. You would need to port app-schemas sql-datastore as well, or
refactor the code to remove the dependency.

Sorry if this is not good news, and I feel for you..

Rob

Thanks Andy,

yes - it is a suprise - I guess we havent matured out of WFS as an
extension of separate GIS functions and into spatially enabled
business applications yet.

We will have to make it work, as we will have observational data of
all sorts using this, as well as 1D and 3D geometries which will need
the same mechanisms.

Stay tuned

Rob

On Thu, Oct 1, 2009 at 11:20 AM, Andrew Rowan
<andrew.rowan@anonymised.com> wrote:

Well, yes, you're right that this isn't the answer I'd hoped for. But
the good news is I need look no further for an answer. I guess for the
time being I'll see about using a separate instance at 1.6 using the
community schemas as documented, and see how that goes.

As far as voices and priorities, I will say that I've been surprised
there isn't more demand for at least the simple case of xy pairs
representing point locations in a non-spatially-enabled database table
... surprised that it isn't a mainstream requirement by now to do what
the "locationsxy" code does. We (state government in New Jersey-USA)
are getting increasing demand for lightweight, simple mashup apps that
combine some particular business data set with a standard pre-rendered
base map. And in many of these cases, the canonical source for the
locations is some table or other in a database that is not managed as
spatial data, but does include location information. Traffic cameras,
park-and-ride lots, geodetic monuments, water wells, etc. We
conceptualized a connector that would respond to a WFS request by
retrieving records (possibly within a BBOX) from a table and delivering
them in GeoJSON to an Open Layers client app. We see it opening up a
huge variety of data t
o being displayed on a map, which will be the first foray into GIS for
many of these agencies.

Unfortunately, I have no resources to offer to help make it happen in
Geoserver. It's a tight time for us. So I will see about making it
work with what's out there.

Thanks for the quick reply.

-Andy

----- Original Message -----
From: Rob Atkinson <robatkinson101@anonymised.com>
Date: Wednesday, September 30, 2009 6:32 pm
Subject: Re: [Geoserver-devel] geometryless

Hi,

dont have the answer you are looking for I expect..

the _plan_ is to replace geometryless by the app-schema functionality.

This can done at the app-schema part - , but is held back by the
broader GML 3 support - we dont have an object model we can map into,
there is a point solution mapping 2D geometry objects into the
bindings. I've been trying to get this relaxed to allow a complete
solution for a while - maybe your voice can help with the priorities.
I cant fix it myself because there is auto-generated code in the loop,
and the autogeneration process is not yet repeatable.

Making it work in 1.7 is feasible, but not as important to me as 2.0
support. You would need to port app-schemas sql-datastore as well, or
refactor the code to remove the dependency.

Sorry if this is not good news, and I feel for you..

Rob

Just wanted to say that here in Massachusetts we're interested in serving
geometryless tables too.
We're running GeoServer 1.7.6, going to version 2 soon. We'll keep an eye on
developments...

Aleda Freeman, GISP
MassGIS
http://www.mass.gov/mgis - MassGIS
http://lyceum.massgis.state.ma.us - Webservices Wiki

--
View this message in context: http://old.nabble.com/geometryless-tp25685894p26799321.html
Sent from the GeoServer - Dev mailing list archive at Nabble.com.

Hi Aleda,

if you want to serve geometryless out of ArcSDE, that's already supported. The non spatial table you want to serve just needs to be an ArcSDE registered table, and then in the DataStore configuration you can enable exposing geometryless registered tables.

Of course that'll expose the introspective structure of the table. If you want to serve an application schema out of them you will need to set up an application schema datastore.

Best regards,
Gabriel

aleda_freeman wrote:

Just wanted to say that here in Massachusetts we're interested in serving
geometryless tables too. We're running GeoServer 1.7.6, going to version 2 soon. We'll keep an eye on
developments...

Aleda Freeman, GISP
MassGIS
http://www.mass.gov/mgis - MassGIS
http://lyceum.massgis.state.ma.us - Webservices Wiki

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

I thought you said it was possible, but then went I looked for
documentation I convinced myself that was still in progress.
OK, I've created a table in SDE with SQLplus called AFREEMAN.NOGEOM_TEST
with two fields and two records. I can see this table in ArcCatalog.
I'm in the GeoServer 2.0 GUI, I found the Feature Data Set Editor now.
But the key piece of info:

ArcSDE_jndiReferenceName: java:comp/env/geotools/arcsde - do
I need to put something here to point to AFREEMAN.NOGEOM_TEST?
database.version: seems optional, there's no red star

datastore.allowNonSpatialTables: (I assume I make this true)

I'm guessing that I also need to setup the Oracle plugin which I haven't
done yet.

Freeman, Aleda (EEA) wrote:

I thought you said it was possible, but then went I looked for
documentation I convinced myself that was still in progress.
OK, I've created a table in SDE with SQLplus called AFREEMAN.NOGEOM_TEST
with two fields and two records. I can see this table in ArcCatalog.
I'm in the GeoServer 2.0 GUI, I found the Feature Data Set Editor now.
But the key piece of info:

ArcSDE_jndiReferenceName: java:comp/env/geotools/arcsde - do
I need to put something here to point to AFREEMAN.NOGEOM_TEST?
database.version: seems optional, there's no red star

datastore.allowNonSpatialTables: (I assume I make this true)

Looks like you've selected the ArcSDE JNDI DataStore instead of the normal ArcSDE DataStore. For the JNDI one to work you need to first have configured the JNDI connection pool in the servlet container.
I assume that wasn't your intention? If so go back to creating a new DataStore and make sure you select the usual ArcSDE one and not the JNDI one.
You don't need to set up Oracle anything to get it working. But just make sure the geometry less table is registered in arcsde (like in with sdetable -o register, may be ArcCatalog already did that? not sure).

Hope that helps,

Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

I think I'm making this too hard. OK, sounds like I don't need any
Oracle plugins.
Maybe the table is not registered, let me try sdetable -o register.
Just because I can see it in ArcCatalog might not mean that it's
registered.

OK, did that:

[afreeman@anonymised.com ~]$ sdetable -o register -t nogeom_test -u afreeman
ArcSDE 9.2 for Oracle10g Build 1247 Tue Apr 29 21:50:50 2008
Attribute Administration Utility
-----------------------------------------------------
Table nogeom_test successfully registered.

OK, back in GeoServer 1.7.7 UI: creating new datastore, choose "ArcSDE",
type a name for Feature Data Set ID "aleda_nogeom_test".
Click "New" button... ah, new page ... I'm guessing I need to say
datastore.allowNonSpatialTables: true.
On this page is server, port, instance, user, etc.

OK, I got through adding the database info there.. and I saved.
But where do I put the table name... still haven't entered that
anywhere.
Do I make a FeatureType out of that Data Store?
When I try to do that I see only real spatial datalayers listed.

I feel like I'm getting closer, am I poking at the right area in the UI
now?

Do the tables need to be registered as versioned? That would seem
excessive.

-----Original Message-----
From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Tuesday, December 15, 2009 3:21 PM
To: Freeman, Aleda (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] geometryless

Freeman, Aleda (EEA) wrote:

I thought you said it was possible, but then went I looked for
documentation I convinced myself that was still in progress.
OK, I've created a table in SDE with SQLplus called
AFREEMAN.NOGEOM_TEST with two fields and two records. I can see this

table in ArcCatalog.

I'm in the GeoServer 2.0 GUI, I found the Feature Data Set Editor now.
But the key piece of info:

ArcSDE_jndiReferenceName: java:comp/env/geotools/arcsde - do
I need to put something here to point to AFREEMAN.NOGEOM_TEST?
database.version: seems optional, there's no red star

datastore.allowNonSpatialTables: (I assume I make this true)

Looks like you've selected the ArcSDE JNDI DataStore instead of the
normal ArcSDE DataStore. For the JNDI one to work you need to first have
configured the JNDI connection pool in the servlet container.
I assume that wasn't your intention? If so go back to creating a new
DataStore and make sure you select the usual ArcSDE one and not the JNDI
one.
You don't need to set up Oracle anything to get it working. But just
make sure the geometry less table is registered in arcsde (like in with
sdetable -o register, may be ArcCatalog already did that? not sure).

Hope that helps,

Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Freeman, Aleda (EEA) wrote:

I think I'm making this too hard. OK, sounds like I don't need any
Oracle plugins.
Maybe the table is not registered, let me try sdetable -o register. Just because I can see it in ArcCatalog might not mean that it's
registered.

OK, did that:

[afreeman@anonymised.com ~]$ sdetable -o register -t nogeom_test -u afreeman
ArcSDE 9.2 for Oracle10g Build 1247 Tue Apr 29 21:50:50 2008
Attribute Administration Utility
-----------------------------------------------------
Table nogeom_test successfully registered.

OK, back in GeoServer 1.7.7 UI: creating new datastore, choose "ArcSDE",
type a name for Feature Data Set ID "aleda_nogeom_test".
Click "New" button... ah, new page ... I'm guessing I need to say
datastore.allowNonSpatialTables: true.
On this page is server, port, instance, user, etc.

OK, I got through adding the database info there.. and I saved. But where do I put the table name... still haven't entered that
anywhere.
Do I make a FeatureType out of that Data Store? When I try to do that I see only real spatial datalayers listed.

I feel like I'm getting closer, am I poking at the right area in the UI
now?

that's alright so far, but the table should have been listed as an available featuretype after you created the datastore, just like for any usual spatial table.

Do the tables need to be registered as versioned? That would seem
excessive.

no, no need to be versioned.
But if you created the datastore with the allow non spatial tables check enabled, then when going to add a new FT from that datastore the table name should appear. Doesn't it?

Gabriel

Hi Andy and list,

Sorry for the very late reply.

There is an open source GIS library called Terralib that implements a
GIS API for non-spatial-databases. It does so by creating tables to
hold geometries and metadata (list of layers, relation to attributes
in non-spatial tables) and providing an API to manipulate it.

Here at Tecgraf/PUC-RJ, we used this library until 2 years ago, when
we started moving to GeoTools/GeoServer.
But we have some projects that were implemented using
non-spatial-databases (Sql-Server and even Access), so we developed a
datastore as a GeoTools plugin to write and read from Terralib managed
databases. Now we have GeoTools and GeoServer reading from these
non-spatial databases.

It's not exactly what you said want, but maybe you could use a
featureType with a point as defaultGeometry and attributes.

The plugin in still under development, there are some limitations and
some things that GeoTools supports that haven't been implemented yet
(transactions for ie). Terralib is implemented in C++, we use JNI to
access its dynamic libraries (we only have compiled and tested dlls
for Windows), so performance is not that good. We are using a memory
cache to improve performance (we are currently working a little on
that to make the cache completely independent from our application
code).

If you (or anyone else) think this might be useful, let me know.

Best regards,
Fabio

On Tue, Dec 15, 2009 at 6:53 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Freeman, Aleda (EEA) wrote:

I think I'm making this too hard. OK, sounds like I don't need any
Oracle plugins.
Maybe the table is not registered, let me try sdetable -o register.
Just because I can see it in ArcCatalog might not mean that it's
registered.

OK, did that:

[afreeman@anonymised.com ~]$ sdetable -o register -t nogeom_test -u afreeman
ArcSDE 9.2 for Oracle10g Build 1247 Tue Apr 29 21:50:50 2008
Attribute Administration Utility
-----------------------------------------------------
Table nogeom_test successfully registered.

OK, back in GeoServer 1.7.7 UI: creating new datastore, choose "ArcSDE",
type a name for Feature Data Set ID "aleda_nogeom_test".
Click "New" button... ah, new page ... I'm guessing I need to say
datastore.allowNonSpatialTables: true.
On this page is server, port, instance, user, etc.

OK, I got through adding the database info there.. and I saved.
But where do I put the table name... still haven't entered that
anywhere.
Do I make a FeatureType out of that Data Store?
When I try to do that I see only real spatial datalayers listed.

I feel like I'm getting closer, am I poking at the right area in the UI
now?

that's alright so far, but the table should have been listed as an
available featuretype after you created the datastore, just like for any
usual spatial table.

Do the tables need to be registered as versioned? That would seem
excessive.

no, no need to be versioned.
But if you created the datastore with the allow non spatial tables check
enabled, then when going to add a new FT from that datastore the table
name should appear. Doesn't it?

Gabriel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

There was a "spatial db in a box" project a while back that taught the pure java databases SFSQL making use of the JTS library.
- http://geoserver.org/display/GEOS/SpatialDBBox

It was successful; but dismissed by the lead developer due to the many limitations of the Java databases at the time (many limited the size of spatial constructs to 32k - and since he was working with some massive individual geometries he was not keen). The other limitation was a facility to hook up a spatial index.

Now some progress may of been made on these issues as it has been a couple of years.

Jody

On 19/01/2010, at 6:10 AM, Fabio Mano wrote:

Hi Andy and list,

Sorry for the very late reply.

There is an open source GIS library called Terralib that implements a
GIS API for non-spatial-databases. It does so by creating tables to
hold geometries and metadata (list of layers, relation to attributes
in non-spatial tables) and providing an API to manipulate it.

Here at Tecgraf/PUC-RJ, we used this library until 2 years ago, when
we started moving to GeoTools/GeoServer.
But we have some projects that were implemented using
non-spatial-databases (Sql-Server and even Access), so we developed a
datastore as a GeoTools plugin to write and read from Terralib managed
databases. Now we have GeoTools and GeoServer reading from these
non-spatial databases.

It's not exactly what you said want, but maybe you could use a
featureType with a point as defaultGeometry and attributes.

The plugin in still under development, there are some limitations and
some things that GeoTools supports that haven't been implemented yet
(transactions for ie). Terralib is implemented in C++, we use JNI to
access its dynamic libraries (we only have compiled and tested dlls
for Windows), so performance is not that good. We are using a memory
cache to improve performance (we are currently working a little on
that to make the cache completely independent from our application
code).

If you (or anyone else) think this might be useful, let me know.

Best regards,
Fabio

On Tue, Dec 15, 2009 at 6:53 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Freeman, Aleda (EEA) wrote:

I think I'm making this too hard. OK, sounds like I don't need any
Oracle plugins.
Maybe the table is not registered, let me try sdetable -o register.
Just because I can see it in ArcCatalog might not mean that it's
registered.

OK, did that:

[afreeman@anonymised.com ~]$ sdetable -o register -t nogeom_test -u afreeman
ArcSDE 9.2 for Oracle10g Build 1247 Tue Apr 29 21:50:50 2008
Attribute Administration Utility
-----------------------------------------------------
Table nogeom_test successfully registered.

OK, back in GeoServer 1.7.7 UI: creating new datastore, choose "ArcSDE",
type a name for Feature Data Set ID "aleda_nogeom_test".
Click "New" button... ah, new page ... I'm guessing I need to say
datastore.allowNonSpatialTables: true.
On this page is server, port, instance, user, etc.

OK, I got through adding the database info there.. and I saved.
But where do I put the table name... still haven't entered that
anywhere.
Do I make a FeatureType out of that Data Store?
When I try to do that I see only real spatial datalayers listed.

I feel like I'm getting closer, am I poking at the right area in the UI
now?

that's alright so far, but the table should have been listed as an
available featuretype after you created the datastore, just like for any
usual spatial table.

Do the tables need to be registered as versioned? That would seem
excessive.

no, no need to be versioned.
But if you created the datastore with the allow non spatial tables check
enabled, then when going to add a new FT from that datastore the table
name should appear. Doesn't it?

Gabriel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Jody Garnett ha scritto:

There was a "spatial db in a box" project a while back that taught the pure java databases SFSQL making use of the JTS library.
- http://geoserver.org/display/GEOS/SpatialDBBox

It was successful; but dismissed by the lead developer due to the many limitations of the Java databases at the time (many limited the size of spatial constructs to 32k - and since he was working with some massive individual geometries he was not keen). The other limitation was a facility to hook up a spatial index.

Now some progress may of been made on these issues as it has been a couple of years.

As far as I know the gt-jdbc-h2 module is the successor
of spatial db in a box. It stores geometries in wkb format in the
H2 database, however just like its predecessor does not have a native
spatial index. And, as far as I know, does not allow to map x,y columns
into a point.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.