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.
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.
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! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
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 ->
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 <brentowens@anonymised.com> 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.
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!
>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Geoserver-users mailing list
>Geoserver-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
>
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.
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 ->
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 <brentowens@anonymised.com> 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.
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! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net 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_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Brent -- some good input. Just curious, when is the new complex
feature model supported in GeoServer / GeoTools?
On 12/27/05, Brent Owens <brentowens@anonymised.com> 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 <brentowens@anonymised.com> 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!
>>>>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>>>>_______________________________________________
>>>>Geoserver-users mailing list
>>>>Geoserver-users@lists.sourceforge.net
>>>>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_idv37&alloc_id865&op=click
>>_______________________________________________
>>Geoserver-users mailing list
>>Geoserver-users@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
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 <brentowens@anonymised.com> 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 ->
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 <brentowens@anonymised.com> 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.
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! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net 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_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net 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_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
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 <brentowens@anonymised.com> 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 ->
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 <brentowens@anonymised.com> 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.
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! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net 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_idv37&alloc_id865&op=click
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
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
There are others that really need it in trunk, so they are helping out.