Hi all,
Further issues with rendering Oracle features in WMS:
Please see image: http://tinyurl.com/2wkthu
The yellow shaded area is a polyline (according to Oracle) and is valid but geoserver seems to be shading it as a polygon by adding a line from the start point to the end point. Notice that the thick yellow border is actually rendered correctly. The feature should not be shaded at all since it is lines not a polygon.
Oracle query on the specific feature:
select t.geoloc.get_gtype() as GTYPE, sdo_geom.validate_geometry_with_context(geoloc, 0.005) as VALID
from my_table t
where id=7960;
GTYPE VALID
6 TRUE
1 rows selected
Oracle Docs say GTYPE 6 is: “MULTILINE or MULTICURVE Geometry has one or more line strings. (MULTILINE and MULTICURVE are synonymous in this context, and each is a superset of both LINE and CURVE.)”
see: http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_objrelschema.htm
Any ideas anyone?
cheers,
Tom
Tom (JDi Solutions) ha scritto:
Hi all,
Further issues with rendering Oracle features in WMS:
Please see image: http://tinyurl.com/2wkthu
The yellow shaded area is a polyline (according to Oracle) and is valid but geoserver seems to be shading it as a polygon by adding a line from the start point to the end point. Notice that the thick yellow border is actually rendered correctly. The feature should not be shaded at all since it is lines not a polygon.
Oracle query on the specific feature:
select t.geoloc.get_gtype() as GTYPE, sdo_geom.validate_geometry_with_context(geoloc, 0.005) as VALID
from my_table t
where id=7960;
GTYPE VALID
----------------------------
6 TRUE
1 rows selected
Oracle Docs say GTYPE 6 is: "MULTILINE or MULTICURVE Geometry has one or more line strings. (MULTILINE and MULTICURVE are synonymous in this context, and each is a superset of both LINE and CURVE.)"
see: http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_objrelschema.htm
Any ideas anyone?
Yes. It's the standard behaviour of our renderer apparently (frankly,
wasn't aware of it), if you apply a fill to a polyline, it'll try to fill it anyways closing the gaps between the start and end point using a
straight line.
Usually this is not a problem, since normally GIS data have separate
tables for different geometry types, but in your specific case they
are all mixed up (it's a MapInfo "feature").
The quickest solution is to have different tables in your case too,
or to add a field identifying the nature of the geometry that
you can then use to filter out and apply the right symbolizer.
Cheers
Andrea
Andrea Aime ha scritto:
Any ideas anyone?
Yes. It's the standard behaviour of our renderer apparently (frankly,
wasn't aware of it), if you apply a fill to a polyline, it'll try to fill it anyways closing the gaps between the start and end point using a
straight line.
Well, inspected the code, found a comment that lead me to the SLD spec,
and turns out we're just respecting the SLD specification.
The PolygonSymbolizer section states:
---------------------------------------------------------------------
If a line is referenced, then the line (string) is closed for filling
(only) by connecting its end point to its start point, any line crossings are corrected in
some way, and only the original line is stroked.
---------------------------------------------------------------------
Exactly what's happening to you.
Cheers
Andrea
Thanks for looking into that and it’s always good to know that the spec is being followed to the letter but in this case isn’t the spec wrong? When presenting data the one thing you absolutely do not do is change it and that’s what’s happening here. A line data type is being presented as a polygon which it isn’t and surely the fill style should only be applied if the object requires a fill and ignored if it doesn’t. Instead an extra point is being added so that it can be filled! Crazy!
It’s not just MapInfo that allows multiple different types of feature, Oracle does too and IMHO it’s an unnecessary limitation of ESRI’s format that you can only have one type per table. Tables should be arranged according to the type of data they hold, not the data itself.
In order to fix this I will have to create a view on the table which will extract the type of shape and then double the number of styles in the .sld file! That seems excessive.
Am I on my own here or does anyone agree that it seems silly to shade polygons which are in fact lines!?
Tom
On 6/1/07, Andrea Aime <aaime@anonymised.com> wrote:
Andrea Aime ha scritto:
Any ideas anyone?
Yes. It’s the standard behaviour of our renderer apparently (frankly,
wasn’t aware of it), if you apply a fill to a polyline, it’ll try to
fill it anyways closing the gaps between the start and end point using a
straight line.
Well, inspected the code, found a comment that lead me to the SLD spec,
and turns out we’re just respecting the SLD specification.
The PolygonSymbolizer section states:
If a line is referenced, then the line (string) is closed for filling
(only) by connecting its end point to its start point, any line
crossings are corrected in
some way, and only the original line is stroked.
Exactly what’s happening to you.
Cheers
Andrea
Tom (JDi Solutions) ha scritto:
Thanks for looking into that and it's always good to know that the spec is being followed to the letter but in this case isn't the spec wrong?
I've seen both cases. Data coming from... I don't remember what software, maybe Autocad, that was polylines, but they needed to
be filled as polygons (pure Autocad does not have the notion
of a polygon as far as I remember).
And then I've seen data coming from MapInfo, that is the opposite
(just once, MapInfo has never been very popular here in Italy, whilst
Autocad is horribly popular...).
Besides these cases, I've been taught at university to do GIS variations
of E/R diagrams where the nature of the geometry was a discriminator,
no mixed geometries were allowed (it was considered a mistake at the exam), so basically I always took that approach as the "rigth one".
Also stuff like Postgis tend towards this approach, in that it adds
checks to ensure you cannot put a line into a polygon column, thought
you can relax it and say it's just a generic geometry I think.
Am I on my own here or does anyone agree that it seems silly to shade polygons which are in fact lines!?
Well, in fact I've been suprised a little myself too, since I did
not remember the SLD spec this well. But I was surprised to find out
you are mixing polylines and polygons in the same table, too.
We could add a vendor option for this, that would require changing
some 5-10 classes in order to make the new option go from the
upper levels of the WMS service to the class that does actually draw
stuff.
Cheers
Andrea
On 6/4/07, Andrea Aime <aaime@anonymised.com> wrote:
Tom (JDi Solutions) ha scritto:
Thanks for looking into that and it’s always good to know that the spec
is being followed to the letter but in this case isn’t the spec wrong?
I’ve seen both cases. Data coming from… I don’t remember what
software, maybe Autocad, that was polylines, but they needed to
be filled as polygons (pure Autocad does not have the notion
of a polygon as far as I remember).
And then I’ve seen data coming from MapInfo, that is the opposite
(just once, MapInfo has never been very popular here in Italy, whilst
Autocad is horribly popular…).
Besides these cases, I’ve been taught at university to do GIS variations
of E/R diagrams where the nature of the geometry was a discriminator,
no mixed geometries were allowed (it was considered a mistake at the
exam), so basically I always took that approach as the “rigth one”.
I have heard this before but it just doesn’t make sense. Maybe one day I’ll find out why!
Also stuff like Postgis tend towards this approach, in that it adds
checks to ensure you cannot put a line into a polygon column, thought
you can relax it and say it’s just a generic geometry I think.
Am I on my own here or does anyone agree that it seems silly to shade
polygons which are in fact lines!?
Well, in fact I’ve been suprised a little myself too, since I did
not remember the SLD spec this well. But I was surprised to find out
you are mixing polylines and polygons in the same table, too.
We could add a vendor option for this, that would require changing
some 5-10 classes in order to make the new option go from the
upper levels of the WMS service to the class that does actually draw
stuff.
Probably not worth it though my solution will be to create 2 styles for every one object type. One for filled polygons and one for lines and then add a field to the table to identify which it is and that’s going to be hassle to do that for all styles too. Oh well 
Cheers
Andrea
Thanks again.
Tom
Tom (JDi Solutions) ha scritto:
Probably not worth it though my solution will be to create 2 styles for every one object type. One for filled polygons and one for lines and then add a field to the table to identify which it is and that's going
Well, we're quite on the OGC standards, but we like to listen to users
as well. Tom, can you open a jira issue for this, citing this thread (you can find a full archive on Nabble)? If more users ask for
it, we'll have enough incentive to implement this as a vendor parameter
(which allows us to break the standard as we like, since it can
be an explicit request for a different behaviour).
Cheers
Andrea
No problem, see: http://jira.codehaus.org/browse/GEOS-1123
On 6/4/07, Andrea Aime < aaime@anonymised.com> wrote:
Tom (JDi Solutions) ha scritto:
Probably not worth it though my solution will be to create 2 styles for
every one object type. One for filled polygons and one for lines and
then add a field to the table to identify which it is and that’s going
Well, we’re quite on the OGC standards, but we like to listen to users
as well. Tom, can you open a jira issue for this, citing this thread
(you can find a full archive on Nabble)? If more users ask for
it, we’ll have enough incentive to implement this as a vendor parameter
(which allows us to break the standard as we like, since it can
be an explicit request for a different behaviour).
Cheers
Andrea