Feature/Attribute question - complex Feature

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature/Attribute question - complex Feature

Davis Ford-3
How does GeoServer/GeoTools deal with complex features?

For example, we have a Feature called road element, and it looks
something like this:

int attributeA
int attributeB
ArrayList<Edge> edges

where Edge is a class defined like:

int attributeA
int attributeB
com.vividsolutions.jts.geom.LineString

So..the geometry is really buried in an Edge, and the feature has an
array full of edges.

Using WFS, we can get GML back, and it represent the int attributes,
but only the pointer to the array list.

WMS fails completely, and my guess is the way we structured this is
causing it.  I would love any pointers that could help.  I'm guessing
we might have to pull the LineStrings out of this Edge class, but the
problem is the number of these Edges is variable depending on the
database.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Brent Owens
The complex feature model should solve this for you. It is currently
under development on another branch and is waiting to be merged back
into trunk on both geoserver and geotools.

Here is some documentation on it:
http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
http://geotools.org/display/GEOTOOLS/Feature+Model+Design

For a temporary solution, I would just query the edge layer for WMS.
What do you mean by "the problem is the number of these Edges is
variable depending on the database"?

Brent Owens
(The Open Planning Project)



Davis Ford wrote:

>How does GeoServer/GeoTools deal with complex features?
>
>For example, we have a Feature called road element, and it looks
>something like this:
>
>int attributeA
>int attributeB
>ArrayList<Edge> edges
>
>where Edge is a class defined like:
>
>int attributeA
>int attributeB
>com.vividsolutions.jts.geom.LineString
>
>So..the geometry is really buried in an Edge, and the feature has an
>array full of edges.
>
>Using WFS, we can get GML back, and it represent the int attributes,
>but only the pointer to the array list.
>
>WMS fails completely, and my guess is the way we structured this is
>causing it.  I would love any pointers that could help.  I'm guessing
>we might have to pull the LineStrings out of this Edge class, but the
>problem is the number of these Edges is variable depending on the
>database.
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Geoserver-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>  
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Davis Ford-3
Hi Brent, (disclaimer: I am a bit new to GIS...still learning)

I'm not sure what you mean when you say just query the edge layer for
WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
represented as the RoadElement layer.

I'm wondering if instead of defining our own Edge class, and having
the road element contain an array of edges (where each edge contains a
LineString), we should instead have the road element contain a
MultiLineString ->

http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html

What I meant with the database comment: road elements features are
populated from the database -- and are represented really as line
segments, the number of which depend on the data and the bounding box.

On 12/21/05, Brent Owens <[hidden email]> wrote:

> The complex feature model should solve this for you. It is currently
> under development on another branch and is waiting to be merged back
> into trunk on both geoserver and geotools.
>
> Here is some documentation on it:
> http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
> http://geotools.org/display/GEOTOOLS/Feature+Model+Design
>
> For a temporary solution, I would just query the edge layer for WMS.
> What do you mean by "the problem is the number of these Edges is
> variable depending on the database"?
>
> Brent Owens
> (The Open Planning Project)
>
>
>
> Davis Ford wrote:
>
> >How does GeoServer/GeoTools deal with complex features?
> >
> >For example, we have a Feature called road element, and it looks
> >something like this:
> >
> >int attributeA
> >int attributeB
> >ArrayList<Edge> edges
> >
> >where Edge is a class defined like:
> >
> >int attributeA
> >int attributeB
> >com.vividsolutions.jts.geom.LineString
> >
> >So..the geometry is really buried in an Edge, and the feature has an
> >array full of edges.
> >
> >Using WFS, we can get GML back, and it represent the int attributes,
> >but only the pointer to the array list.
> >
> >WMS fails completely, and my guess is the way we structured this is
> >causing it.  I would love any pointers that could help.  I'm guessing
> >we might have to pull the LineStrings out of this Edge class, but the
> >problem is the number of these Edges is variable depending on the
> >database.
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> >for problems?  Stop!  Download the new AJAX search engine that makes
> >searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> ><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> >_______________________________________________
> >Geoserver-users mailing list
> >[hidden email]
> >https://lists.sourceforge.net/lists/listinfo/geoserver-users
> >
> >
> >
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Hans-Ulrich Otto
Hi Davis and Brent,

if I may join your discussion.

The model Davis wants to publish (in fact our Tele Atlas data model) is a topological one, i.e. we have features such as road elements that include a list of attributes but they do not include the geometry directly via a mdsys.sdo_geometry attribute. Instead they have references to topological primitive edge. The topological promitives node, edge, and face represent a planar graph and the nodes and edges carry geometric information.

Oracle supports such a model natively since 10g R 10.1.0.4, by introducing a new type mdsys.sdo_topo_geometry in a model called Mini Topology. If you create a table with such a type, Oracle manages for you node$, edge$ and face$ system tables as well as relation$ tables with the corresponding features and also maintains the topological correctness. You can do almost the same spatial operations on sdo_topo_geometry than on sdo_geomtry, of cource also creating spatial indexes. Editing data in the Mini Topo model seems to be however cumbersome.

So in my point of view one questions is whether or not the Oracle connector of geoserver/geotools supports the new type mdsys.sdo_topo_geometry. This would be one solution for the problem.

Using a complex feature would be another solution, however requires to model the edges as feature in a spatial layer, which they conceptualy not are, and model simple features as complex ones (which they alsao not are, as we have realcomplex features on top of our simple ones). Another disadvantage is that you cannot make direct spatial queries on the feature itself but always have to join with the edge layer, and also cannot publish the feature layer directly but have to go via a view which is less performant.

A third solution is to keep geometry redundant for both feature and endges which may let you run into consistency problems if not properly syncronised.

So each choice has certain advantages or disadvantages. Hope this helps you further.

Merry Xmas,

Uli.



Davis Ford wrote:
Hi Brent, (disclaimer: I am a bit new to GIS...still learning)

I'm not sure what you mean when you say just query the edge layer for
WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
represented as the RoadElement layer.

I'm wondering if instead of defining our own Edge class, and having
the road element contain an array of edges (where each edge contains a
LineString), we should instead have the road element contain a
MultiLineString ->

http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html

What I meant with the database comment: road elements features are
populated from the database -- and are represented really as line
segments, the number of which depend on the data and the bounding box.

On 12/21/05, Brent Owens [hidden email] wrote:
  
The complex feature model should solve this for you. It is currently
under development on another branch and is waiting to be merged back
into trunk on both geoserver and geotools.

Here is some documentation on it:
http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
http://geotools.org/display/GEOTOOLS/Feature+Model+Design

For a temporary solution, I would just query the edge layer for WMS.
What do you mean by "the problem is the number of these Edges is
variable depending on the database"?

Brent Owens
(The Open Planning Project)



Davis Ford wrote:

    
How does GeoServer/GeoTools deal with complex features?

For example, we have a Feature called road element, and it looks
something like this:

int attributeA
int attributeB
ArrayList<Edge> edges

where Edge is a class defined like:

int attributeA
int attributeB
com.vividsolutions.jts.geom.LineString

So..the geometry is really buried in an Edge, and the feature has an
array full of edges.

Using WFS, we can get GML back, and it represent the int attributes,
but only the pointer to the array list.

WMS fails completely, and my guess is the way we structured this is
causing it.  I would love any pointers that could help.  I'm guessing
we might have to pull the LineStrings out of this Edge class, but the
problem is the number of these Edges is variable depending on the
database.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users



      


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
  
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Brent Owens
Hi Davis, Hans

It is best not to change your model based on the technology you are
using. Having a duplicate multi-linestring for your road element
(containing all of the edge line strings) it not the best way to go. You
have twice the amount of data, and as Hans said, you have to maintain
two sets... not fun.

The way I see it as you described, you have a conceptual road segment;
built up of actual edges (containing the line string). You have a table
for road segments, and a table for road edges. If you create a layer
that points to your road edges, where the actual geometries are,
Geoserver will be able to render them. That will solve your WMS problem,
but your GML will only contain the edge data. You will need the new
complex feature model to have them both work together well.

As for the topology, Hans has a good suggestion. But if you don't need
much topology work, then I wouldn't worry about it as it can get quite
complex (and Oracle isn't free).
I can't remember the state of PostGIS's topology.
But that is all up to your requirements and model.

Brent Owens
TOPP



Hans-Ulrich Otto wrote:

> Hi Davis and Brent,
>
> if I may join your discussion.
>
> The model Davis wants to publish (in fact our Tele Atlas data model)
> is a topological one, i.e. we have features such as road elements that
> include a list of attributes but they do not include the geometry
> directly via a mdsys.sdo_geometry attribute. Instead they have
> references to topological primitive edge. The topological promitives
> node, edge, and face represent a planar graph and the nodes and edges
> carry geometric information.
>
> Oracle supports such a model natively since 10g R 10.1.0.4, by
> introducing a new type mdsys.sdo_topo_geometry in a model called Mini
> Topology. If you create a table with such a type, Oracle manages for
> you node$, edge$ and face$ system tables as well as relation$ tables
> with the corresponding features and also maintains the topological
> correctness. You can do almost the same spatial operations on
> sdo_topo_geometry than on sdo_geomtry, of cource also creating spatial
> indexes. Editing data in the Mini Topo model seems to be however
> cumbersome.
>
> So in my point of view one questions is whether or not the Oracle
> connector of geoserver/geotools supports the new type
> mdsys.sdo_topo_geometry. This would be one solution for the problem.
>
> Using a complex feature would be another solution, however requires to
> model the edges as feature in a spatial layer, which they conceptualy
> not are, and model simple features as complex ones (which they alsao
> not are, as we have realcomplex features on top of our simple ones).
> Another disadvantage is that you cannot make direct spatial queries on
> the feature itself but always have to join with the edge layer, and
> also cannot publish the feature layer directly but have to go via a
> view which is less performant.
>
> A third solution is to keep geometry redundant for both feature and
> endges which may let you run into consistency problems if not properly
> syncronised.
>
> So each choice has certain advantages or disadvantages. Hope this
> helps you further.
>
> Merry Xmas,
>
> Uli.
>
>
>
> Davis Ford wrote:
>
>>Hi Brent, (disclaimer: I am a bit new to GIS...still learning)
>>
>>I'm not sure what you mean when you say just query the edge layer for
>>WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
>>represented as the RoadElement layer.
>>
>>I'm wondering if instead of defining our own Edge class, and having
>>the road element contain an array of edges (where each edge contains a
>>LineString), we should instead have the road element contain a
>>MultiLineString ->
>>
>>http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html
>>
>>What I meant with the database comment: road elements features are
>>populated from the database -- and are represented really as line
>>segments, the number of which depend on the data and the bounding box.
>>
>>On 12/21/05, Brent Owens <[hidden email]> wrote:
>>  
>>
>>>The complex feature model should solve this for you. It is currently
>>>under development on another branch and is waiting to be merged back
>>>into trunk on both geoserver and geotools.
>>>
>>>Here is some documentation on it:
>>>http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
>>>http://geotools.org/display/GEOTOOLS/Feature+Model+Design
>>>
>>>For a temporary solution, I would just query the edge layer for WMS.
>>>What do you mean by "the problem is the number of these Edges is
>>>variable depending on the database"?
>>>
>>>Brent Owens
>>>(The Open Planning Project)
>>>
>>>
>>>
>>>Davis Ford wrote:
>>>
>>>    
>>>
>>>>How does GeoServer/GeoTools deal with complex features?
>>>>
>>>>For example, we have a Feature called road element, and it looks
>>>>something like this:
>>>>
>>>>int attributeA
>>>>int attributeB
>>>>ArrayList<Edge> edges
>>>>
>>>>where Edge is a class defined like:
>>>>
>>>>int attributeA
>>>>int attributeB
>>>>com.vividsolutions.jts.geom.LineString
>>>>
>>>>So..the geometry is really buried in an Edge, and the feature has an
>>>>array full of edges.
>>>>
>>>>Using WFS, we can get GML back, and it represent the int attributes,
>>>>but only the pointer to the array list.
>>>>
>>>>WMS fails completely, and my guess is the way we structured this is
>>>>causing it.  I would love any pointers that could help.  I'm guessing
>>>>we might have to pull the LineStrings out of this Edge class, but the
>>>>problem is the number of these Edges is variable depending on the
>>>>database.
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>_______________________________________________
>>>>Geoserver-users mailing list
>>>>[hidden email]
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>>
>>>>
>>>>      
>>>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>_______________________________________________
>>Geoserver-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>  
>>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Davis Ford-3
Brent -- some good input.  Just curious, when is the new complex
feature model supported in GeoServer / GeoTools?

On 12/27/05, Brent Owens <[hidden email]> wrote:

> Hi Davis, Hans
>
> It is best not to change your model based on the technology you are
> using. Having a duplicate multi-linestring for your road element
> (containing all of the edge line strings) it not the best way to go. You
> have twice the amount of data, and as Hans said, you have to maintain
> two sets... not fun.
>
> The way I see it as you described, you have a conceptual road segment;
> built up of actual edges (containing the line string). You have a table
> for road segments, and a table for road edges. If you create a layer
> that points to your road edges, where the actual geometries are,
> Geoserver will be able to render them. That will solve your WMS problem,
> but your GML will only contain the edge data. You will need the new
> complex feature model to have them both work together well.
>
> As for the topology, Hans has a good suggestion. But if you don't need
> much topology work, then I wouldn't worry about it as it can get quite
> complex (and Oracle isn't free).
> I can't remember the state of PostGIS's topology.
> But that is all up to your requirements and model.
>
> Brent Owens
> TOPP
>
>
>
> Hans-Ulrich Otto wrote:
>
> > Hi Davis and Brent,
> >
> > if I may join your discussion.
> >
> > The model Davis wants to publish (in fact our Tele Atlas data model)
> > is a topological one, i.e. we have features such as road elements that
> > include a list of attributes but they do not include the geometry
> > directly via a mdsys.sdo_geometry attribute. Instead they have
> > references to topological primitive edge. The topological promitives
> > node, edge, and face represent a planar graph and the nodes and edges
> > carry geometric information.
> >
> > Oracle supports such a model natively since 10g R 10.1.0.4, by
> > introducing a new type mdsys.sdo_topo_geometry in a model called Mini
> > Topology. If you create a table with such a type, Oracle manages for
> > you node$, edge$ and face$ system tables as well as relation$ tables
> > with the corresponding features and also maintains the topological
> > correctness. You can do almost the same spatial operations on
> > sdo_topo_geometry than on sdo_geomtry, of cource also creating spatial
> > indexes. Editing data in the Mini Topo model seems to be however
> > cumbersome.
> >
> > So in my point of view one questions is whether or not the Oracle
> > connector of geoserver/geotools supports the new type
> > mdsys.sdo_topo_geometry. This would be one solution for the problem.
> >
> > Using a complex feature would be another solution, however requires to
> > model the edges as feature in a spatial layer, which they conceptualy
> > not are, and model simple features as complex ones (which they alsao
> > not are, as we have realcomplex features on top of our simple ones).
> > Another disadvantage is that you cannot make direct spatial queries on
> > the feature itself but always have to join with the edge layer, and
> > also cannot publish the feature layer directly but have to go via a
> > view which is less performant.
> >
> > A third solution is to keep geometry redundant for both feature and
> > endges which may let you run into consistency problems if not properly
> > syncronised.
> >
> > So each choice has certain advantages or disadvantages. Hope this
> > helps you further.
> >
> > Merry Xmas,
> >
> > Uli.
> >
> >
> >
> > Davis Ford wrote:
> >
> >>Hi Brent, (disclaimer: I am a bit new to GIS...still learning)
> >>
> >>I'm not sure what you mean when you say just query the edge layer for
> >>WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
> >>represented as the RoadElement layer.
> >>
> >>I'm wondering if instead of defining our own Edge class, and having
> >>the road element contain an array of edges (where each edge contains a
> >>LineString), we should instead have the road element contain a
> >>MultiLineString ->
> >>
> >>http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html
> >>
> >>What I meant with the database comment: road elements features are
> >>populated from the database -- and are represented really as line
> >>segments, the number of which depend on the data and the bounding box.
> >>
> >>On 12/21/05, Brent Owens <[hidden email]> wrote:
> >>
> >>
> >>>The complex feature model should solve this for you. It is currently
> >>>under development on another branch and is waiting to be merged back
> >>>into trunk on both geoserver and geotools.
> >>>
> >>>Here is some documentation on it:
> >>>http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
> >>>http://geotools.org/display/GEOTOOLS/Feature+Model+Design
> >>>
> >>>For a temporary solution, I would just query the edge layer for WMS.
> >>>What do you mean by "the problem is the number of these Edges is
> >>>variable depending on the database"?
> >>>
> >>>Brent Owens
> >>>(The Open Planning Project)
> >>>
> >>>
> >>>
> >>>Davis Ford wrote:
> >>>
> >>>
> >>>
> >>>>How does GeoServer/GeoTools deal with complex features?
> >>>>
> >>>>For example, we have a Feature called road element, and it looks
> >>>>something like this:
> >>>>
> >>>>int attributeA
> >>>>int attributeB
> >>>>ArrayList<Edge> edges
> >>>>
> >>>>where Edge is a class defined like:
> >>>>
> >>>>int attributeA
> >>>>int attributeB
> >>>>com.vividsolutions.jts.geom.LineString
> >>>>
> >>>>So..the geometry is really buried in an Edge, and the feature has an
> >>>>array full of edges.
> >>>>
> >>>>Using WFS, we can get GML back, and it represent the int attributes,
> >>>>but only the pointer to the array list.
> >>>>
> >>>>WMS fails completely, and my guess is the way we structured this is
> >>>>causing it.  I would love any pointers that could help.  I'm guessing
> >>>>we might have to pull the LineStrings out of this Edge class, but the
> >>>>problem is the number of these Edges is variable depending on the
> >>>>database.
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> >>>>for problems?  Stop!  Download the new AJAX search engine that makes
> >>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> >>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> >>>>_______________________________________________
> >>>>Geoserver-users mailing list
> >>>>[hidden email]
> >>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> >>for problems?  Stop!  Download the new AJAX search engine that makes
> >>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> >><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> >>_______________________________________________
> >>Geoserver-users mailing list
> >>[hidden email]
> >>https://lists.sourceforge.net/lists/listinfo/geoserver-users
> >>
> >>
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Justin Deoliveira-3
Hi Davis,

There is a geotools branch (the new feature model), and a geoserver
branch (the complex data store) that need to come in. I have started
looking at this. After 1.3.0 is out I am hoping we can focus on getting
them in.

-Justin

Davis Ford wrote:

> Brent -- some good input.  Just curious, when is the new complex
> feature model supported in GeoServer / GeoTools?
>
> On 12/27/05, Brent Owens <[hidden email]> wrote:
>
>>Hi Davis, Hans
>>
>>It is best not to change your model based on the technology you are
>>using. Having a duplicate multi-linestring for your road element
>>(containing all of the edge line strings) it not the best way to go. You
>>have twice the amount of data, and as Hans said, you have to maintain
>>two sets... not fun.
>>
>>The way I see it as you described, you have a conceptual road segment;
>>built up of actual edges (containing the line string). You have a table
>>for road segments, and a table for road edges. If you create a layer
>>that points to your road edges, where the actual geometries are,
>>Geoserver will be able to render them. That will solve your WMS problem,
>>but your GML will only contain the edge data. You will need the new
>>complex feature model to have them both work together well.
>>
>>As for the topology, Hans has a good suggestion. But if you don't need
>>much topology work, then I wouldn't worry about it as it can get quite
>>complex (and Oracle isn't free).
>>I can't remember the state of PostGIS's topology.
>>But that is all up to your requirements and model.
>>
>>Brent Owens
>>TOPP
>>
>>
>>
>>Hans-Ulrich Otto wrote:
>>
>>
>>>Hi Davis and Brent,
>>>
>>>if I may join your discussion.
>>>
>>>The model Davis wants to publish (in fact our Tele Atlas data model)
>>>is a topological one, i.e. we have features such as road elements that
>>>include a list of attributes but they do not include the geometry
>>>directly via a mdsys.sdo_geometry attribute. Instead they have
>>>references to topological primitive edge. The topological promitives
>>>node, edge, and face represent a planar graph and the nodes and edges
>>>carry geometric information.
>>>
>>>Oracle supports such a model natively since 10g R 10.1.0.4, by
>>>introducing a new type mdsys.sdo_topo_geometry in a model called Mini
>>>Topology. If you create a table with such a type, Oracle manages for
>>>you node$, edge$ and face$ system tables as well as relation$ tables
>>>with the corresponding features and also maintains the topological
>>>correctness. You can do almost the same spatial operations on
>>>sdo_topo_geometry than on sdo_geomtry, of cource also creating spatial
>>>indexes. Editing data in the Mini Topo model seems to be however
>>>cumbersome.
>>>
>>>So in my point of view one questions is whether or not the Oracle
>>>connector of geoserver/geotools supports the new type
>>>mdsys.sdo_topo_geometry. This would be one solution for the problem.
>>>
>>>Using a complex feature would be another solution, however requires to
>>>model the edges as feature in a spatial layer, which they conceptualy
>>>not are, and model simple features as complex ones (which they alsao
>>>not are, as we have realcomplex features on top of our simple ones).
>>>Another disadvantage is that you cannot make direct spatial queries on
>>>the feature itself but always have to join with the edge layer, and
>>>also cannot publish the feature layer directly but have to go via a
>>>view which is less performant.
>>>
>>>A third solution is to keep geometry redundant for both feature and
>>>endges which may let you run into consistency problems if not properly
>>>syncronised.
>>>
>>>So each choice has certain advantages or disadvantages. Hope this
>>>helps you further.
>>>
>>>Merry Xmas,
>>>
>>>Uli.
>>>
>>>
>>>
>>>Davis Ford wrote:
>>>
>>>
>>>>Hi Brent, (disclaimer: I am a bit new to GIS...still learning)
>>>>
>>>>I'm not sure what you mean when you say just query the edge layer for
>>>>WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
>>>>represented as the RoadElement layer.
>>>>
>>>>I'm wondering if instead of defining our own Edge class, and having
>>>>the road element contain an array of edges (where each edge contains a
>>>>LineString), we should instead have the road element contain a
>>>>MultiLineString ->
>>>>
>>>>http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html
>>>>
>>>>What I meant with the database comment: road elements features are
>>>>populated from the database -- and are represented really as line
>>>>segments, the number of which depend on the data and the bounding box.
>>>>
>>>>On 12/21/05, Brent Owens <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>>>The complex feature model should solve this for you. It is currently
>>>>>under development on another branch and is waiting to be merged back
>>>>>into trunk on both geoserver and geotools.
>>>>>
>>>>>Here is some documentation on it:
>>>>>http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
>>>>>http://geotools.org/display/GEOTOOLS/Feature+Model+Design
>>>>>
>>>>>For a temporary solution, I would just query the edge layer for WMS.
>>>>>What do you mean by "the problem is the number of these Edges is
>>>>>variable depending on the database"?
>>>>>
>>>>>Brent Owens
>>>>>(The Open Planning Project)
>>>>>
>>>>>
>>>>>
>>>>>Davis Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>How does GeoServer/GeoTools deal with complex features?
>>>>>>
>>>>>>For example, we have a Feature called road element, and it looks
>>>>>>something like this:
>>>>>>
>>>>>>int attributeA
>>>>>>int attributeB
>>>>>>ArrayList<Edge> edges
>>>>>>
>>>>>>where Edge is a class defined like:
>>>>>>
>>>>>>int attributeA
>>>>>>int attributeB
>>>>>>com.vividsolutions.jts.geom.LineString
>>>>>>
>>>>>>So..the geometry is really buried in an Edge, and the feature has an
>>>>>>array full of edges.
>>>>>>
>>>>>>Using WFS, we can get GML back, and it represent the int attributes,
>>>>>>but only the pointer to the array list.
>>>>>>
>>>>>>WMS fails completely, and my guess is the way we structured this is
>>>>>>causing it.  I would love any pointers that could help.  I'm guessing
>>>>>>we might have to pull the LineStrings out of this Edge class, but the
>>>>>>problem is the number of these Edges is variable depending on the
>>>>>>database.
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>>>_______________________________________________
>>>>>>Geoserver-users mailing list
>>>>>>[hidden email]
>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>_______________________________________________
>>>>Geoserver-users mailing list
>>>>[hidden email]
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> <a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Geoserver-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>


--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Feature/Attribute question - complex Feature

Brent Owens
In reply to this post by Davis Ford-3
Hi Davis,

It is in a branch right now, but the gears are turning to get it merged
into trunk. There are about 4 branches total, between Geotools and
Geoserver, that need to merge in order for it to get done. Lots of us
have been talking about it and we are going to get started on it this
month, and it will probably take a couple months to complete. But don't
quote me on the time ;) There are others that really need it in trunk,
so they are helping out.

Attending the IRC meetings will be the best bet to get an accurate
timeframe (if there even is one yet). They will be starting up again in
full force next Tuesday.

Brent Owens
TOPP



Davis Ford wrote:

>Brent -- some good input.  Just curious, when is the new complex
>feature model supported in GeoServer / GeoTools?
>
>On 12/27/05, Brent Owens <[hidden email]> wrote:
>  
>
>>Hi Davis, Hans
>>
>>It is best not to change your model based on the technology you are
>>using. Having a duplicate multi-linestring for your road element
>>(containing all of the edge line strings) it not the best way to go. You
>>have twice the amount of data, and as Hans said, you have to maintain
>>two sets... not fun.
>>
>>The way I see it as you described, you have a conceptual road segment;
>>built up of actual edges (containing the line string). You have a table
>>for road segments, and a table for road edges. If you create a layer
>>that points to your road edges, where the actual geometries are,
>>Geoserver will be able to render them. That will solve your WMS problem,
>>but your GML will only contain the edge data. You will need the new
>>complex feature model to have them both work together well.
>>
>>As for the topology, Hans has a good suggestion. But if you don't need
>>much topology work, then I wouldn't worry about it as it can get quite
>>complex (and Oracle isn't free).
>>I can't remember the state of PostGIS's topology.
>>But that is all up to your requirements and model.
>>
>>Brent Owens
>>TOPP
>>
>>
>>
>>Hans-Ulrich Otto wrote:
>>
>>    
>>
>>>Hi Davis and Brent,
>>>
>>>if I may join your discussion.
>>>
>>>The model Davis wants to publish (in fact our Tele Atlas data model)
>>>is a topological one, i.e. we have features such as road elements that
>>>include a list of attributes but they do not include the geometry
>>>directly via a mdsys.sdo_geometry attribute. Instead they have
>>>references to topological primitive edge. The topological promitives
>>>node, edge, and face represent a planar graph and the nodes and edges
>>>carry geometric information.
>>>
>>>Oracle supports such a model natively since 10g R 10.1.0.4, by
>>>introducing a new type mdsys.sdo_topo_geometry in a model called Mini
>>>Topology. If you create a table with such a type, Oracle manages for
>>>you node$, edge$ and face$ system tables as well as relation$ tables
>>>with the corresponding features and also maintains the topological
>>>correctness. You can do almost the same spatial operations on
>>>sdo_topo_geometry than on sdo_geomtry, of cource also creating spatial
>>>indexes. Editing data in the Mini Topo model seems to be however
>>>cumbersome.
>>>
>>>So in my point of view one questions is whether or not the Oracle
>>>connector of geoserver/geotools supports the new type
>>>mdsys.sdo_topo_geometry. This would be one solution for the problem.
>>>
>>>Using a complex feature would be another solution, however requires to
>>>model the edges as feature in a spatial layer, which they conceptualy
>>>not are, and model simple features as complex ones (which they alsao
>>>not are, as we have realcomplex features on top of our simple ones).
>>>Another disadvantage is that you cannot make direct spatial queries on
>>>the feature itself but always have to join with the edge layer, and
>>>also cannot publish the feature layer directly but have to go via a
>>>view which is less performant.
>>>
>>>A third solution is to keep geometry redundant for both feature and
>>>endges which may let you run into consistency problems if not properly
>>>syncronised.
>>>
>>>So each choice has certain advantages or disadvantages. Hope this
>>>helps you further.
>>>
>>>Merry Xmas,
>>>
>>>Uli.
>>>
>>>
>>>
>>>Davis Ford wrote:
>>>
>>>      
>>>
>>>>Hi Brent, (disclaimer: I am a bit new to GIS...still learning)
>>>>
>>>>I'm not sure what you mean when you say just query the edge layer for
>>>>WMS.  Can you elaborate.  I'm pretty sure I only have a single layer
>>>>represented as the RoadElement layer.
>>>>
>>>>I'm wondering if instead of defining our own Edge class, and having
>>>>the road element contain an array of edges (where each edge contains a
>>>>LineString), we should instead have the road element contain a
>>>>MultiLineString ->
>>>>
>>>>http://www.vividsolutions.com/JTS/javadoc/com/vividsolutions/jts/geom/MultiLineString.html
>>>>
>>>>What I meant with the database comment: road elements features are
>>>>populated from the database -- and are represented really as line
>>>>segments, the number of which depend on the data and the bounding box.
>>>>
>>>>On 12/21/05, Brent Owens <[hidden email]> wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>The complex feature model should solve this for you. It is currently
>>>>>under development on another branch and is waiting to be merged back
>>>>>into trunk on both geoserver and geotools.
>>>>>
>>>>>Here is some documentation on it:
>>>>>http://geotools.org/display/GEOTOOLS/ComplexDataStore+project
>>>>>http://geotools.org/display/GEOTOOLS/Feature+Model+Design
>>>>>
>>>>>For a temporary solution, I would just query the edge layer for WMS.
>>>>>What do you mean by "the problem is the number of these Edges is
>>>>>variable depending on the database"?
>>>>>
>>>>>Brent Owens
>>>>>(The Open Planning Project)
>>>>>
>>>>>
>>>>>
>>>>>Davis Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>How does GeoServer/GeoTools deal with complex features?
>>>>>>
>>>>>>For example, we have a Feature called road element, and it looks
>>>>>>something like this:
>>>>>>
>>>>>>int attributeA
>>>>>>int attributeB
>>>>>>ArrayList<Edge> edges
>>>>>>
>>>>>>where Edge is a class defined like:
>>>>>>
>>>>>>int attributeA
>>>>>>int attributeB
>>>>>>com.vividsolutions.jts.geom.LineString
>>>>>>
>>>>>>So..the geometry is really buried in an Edge, and the feature has an
>>>>>>array full of edges.
>>>>>>
>>>>>>Using WFS, we can get GML back, and it represent the int attributes,
>>>>>>but only the pointer to the array list.
>>>>>>
>>>>>>WMS fails completely, and my guess is the way we structured this is
>>>>>>causing it.  I would love any pointers that could help.  I'm guessing
>>>>>>we might have to pull the LineStrings out of this Edge class, but the
>>>>>>problem is the number of these Edges is variable depending on the
>>>>>>database.
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>>>_______________________________________________
>>>>>>Geoserver-users mailing list
>>>>>>[hidden email]
>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>_______________________________________________
>>>>Geoserver-users mailing list
>>>>[hidden email]
>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>>
>>>>        
>>>>
>
>  
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: [Geotools-gt2-users] Feature/Attribute question - complex Feature

Jody Garnett
In reply to this post by Davis Ford-3
Davis Ford wrote:
> How does GeoServer/GeoTools deal with complex features?
>  
The answer is "poorly" - but we have a branch where support is improved
- this seems to be the subject of a forthcoming geoserver project -
intergrating the community schema support (ie complex feature support)
onto trunk.

For more information check out the RnD page.

For your specific case make your List<Edge> into a FeatureCollection,
and we will need to flush out the assumption about default geometry used
by the renderers.  Ie when you specify in the SLD what needs to be
rendered you will need to provide an xpath expression, and then we will
need to implement xpath support.

2 out of those three things are ready on the community schema branches...
Jody



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users