Hi,
I’m trying to make an sld for open street map data such that it appears basically pretty much like Open Street Map / Google Maps presents it and have got this far: http://demo.jdi-consult.net/oltest/osm.php and most things are looking pretty good. The images are rendered in 2 stages, first there’s a background layer where all roads are rendered as grey lines then there is a colour layer on top where the roads are rendered in the appropriate colour depending on the class of road. The second layer is sorted at the database to ensure that the highest priority roads are rendered last and therefore on top which 8/10 times is probably the best way to do it but there is a problem when (as shown in the example url) you get a t-junction where the higher priority road (shown here in orange) joins a lower priority road (in yellow) and is drawn on top, when it should ideally be drawn below.
I’m stumped. Any ideas how to solve this one?
Tom
Tom (JDi Solutions) ha scritto:
Hi,
I'm trying to make an sld for open street map data such that it appears basically pretty much like Open Street Map / Google Maps presents it and have got this far: http://demo.jdi-consult.net/oltest/osm.php and most things are looking pretty good. The images are rendered in 2 stages, first there's a background layer where all roads are rendered as grey lines then there is a colour layer on top where the roads are rendered in the appropriate colour depending on the class of road. The second layer is sorted at the database to ensure that the highest priority roads are rendered last and therefore on top which 8/10 times is probably the best way to do it but there is a problem when (as shown in the example url) you get a t-junction where the higher priority road (shown here in orange) joins a lower priority road (in yellow) and is drawn on top, when it should ideally be drawn below.
I'm stumped. Any ideas how to solve this one?
The only way to have proper ordering out of an SLD is to use multiple
feature type styles in your SLD. So you should have a single
feature type style to draw everything in gray, and then one feature
type style for each colored one, specified in the order you want.
Beware this will require more memory than your current setup, see
also:
http://jira.codehaus.org/browse/GEOS-1372
In any case, if you're hitting a sorted view, I don't really know
why that visual error is happening. The renderer does not ask for
a particular order, but maybe the way the query is resolved by
the db changes the order? I don't know...
Cheers
Andrea
No no, in most instances it works perfect, the roads are rendered with the smallest ones (residential and unclassified) first then the “tertiary” followed by “secondary” then “primary”, “trunk” and finally “motorway” and it works great, when a motorway is rendered it will always overlay any other road type and likewise down the chain and this is ensured by the Oracle view which always returns the records in that order. The problem is that in real life that rule doesn’t always apply. In the example given in order to render it nicely I want the lower priority road (tertiary in yellow) to overlap the higher priority road (secondary in orange) but normally this isn’t the requirement.
Confusing huh? I’m thinking it’s not possible but presumably someone has had this problem before?..
On 10/5/07, Andrea Aime < aaime@anonymised.com> wrote:
Tom (JDi Solutions) ha scritto:
Hi,
I’m trying to make an sld for open street map data such that it appears
basically pretty much like Open Street Map / Google Maps presents it and
have got this far: http://demo.jdi-consult.net/oltest/osm.php and most
things are looking pretty good. The images are rendered in 2 stages,
first there’s a background layer where all roads are rendered as grey
lines then there is a colour layer on top where the roads are rendered
in the appropriate colour depending on the class of road. The second
layer is sorted at the database to ensure that the highest priority
roads are rendered last and therefore on top which 8/10 times is
probably the best way to do it but there is a problem when (as shown in
the example url) you get a t-junction where the higher priority road
(shown here in orange) joins a lower priority road (in yellow) and is
drawn on top, when it should ideally be drawn below.
I’m stumped. Any ideas how to solve this one?
The only way to have proper ordering out of an SLD is to use multiple
feature type styles in your SLD. So you should have a single
feature type style to draw everything in gray, and then one feature
type style for each colored one, specified in the order you want.
Beware this will require more memory than your current setup, see
also:
http://jira.codehaus.org/browse/GEOS-1372
In any case, if you’re hitting a sorted view, I don’t really know
why that visual error is happening. The renderer does not ask for
a particular order, but maybe the way the query is resolved by
the db changes the order? I don’t know…
Cheers
Andrea
Tom (JDi Solutions) ha scritto:
No no, in most instances it works perfect, the roads are rendered with the smallest ones (residential and unclassified) first then the "tertiary" followed by "secondary" then "primary", "trunk" and finally "motorway" and it works great, when a motorway is rendered it will always overlay any other road type and likewise down the chain and this is ensured by the Oracle view which always returns the records in that order. The problem is that in real life that rule doesn't always apply. In the example given in order to render it nicely I want the lower priority road (tertiary in yellow) to overlap the higher priority road (secondary in orange) but normally this isn't the requirement.
Confusing huh? I'm thinking it's not possible but presumably someone has had this problem before?...
Tom, have you tried creating the multiple feature type styles as I
suggested? By the way the renderer operates it should simple be
impossible to have the issue you're reporting, as long as your
style lists each colored "sub-layer" in a separate feature type style.
As why the sorted view approach is not working sometimes, I really
have no idea, I'm just as surprised as you...
Cheers
Andrea
No, the sorted view approach does work, it’s where the roads on the map don’t fit the rule that it doesn’t work so setting up seperate feature types won’t make any difference. The renderer IS rendering the features in the correct order, it’s just that that’s not always the order I need!!! I have been looking at the Open Street Map site and noticed that they seem to have exactly the same problem so I’m assuming it’s a limitation of the data at the moment.
Thanks for your thoughts but I think it’s not going to be possible without some bespoke code in the renderer, basically the combination of the sld and data aren’t going to be enough to solve this so I’m not going to pursue it any further!
On 10/5/07, Andrea Aime <aaime@anonymised.com> wrote:
Tom (JDi Solutions) ha scritto:
No no, in most instances it works perfect, the roads are rendered with
the smallest ones (residential and unclassified) first then the
“tertiary” followed by “secondary” then “primary”, “trunk” and finally
“motorway” and it works great, when a motorway is rendered it will
always overlay any other road type and likewise down the chain and this
is ensured by the Oracle view which always returns the records in that
order. The problem is that in real life that rule doesn’t always
apply. In the example given in order to render it nicely I want the
lower priority road (tertiary in yellow) to overlap the higher priority
road (secondary in orange) but normally this isn’t the requirement.
Confusing huh? I’m thinking it’s not possible but presumably someone
has had this problem before?..
Tom, have you tried creating the multiple feature type styles as I
suggested? By the way the renderer operates it should simple be
impossible to have the issue you’re reporting, as long as your
style lists each colored “sub-layer” in a separate feature type style.
As why the sorted view approach is not working sometimes, I really
have no idea, I’m just as surprised as you…
Cheers
Andrea
Tom (JDi Solutions) ha scritto:
No, the sorted view approach does work, it's where the roads on the map don't fit the rule that it doesn't work so setting up seperate feature types won't make any difference. The renderer IS rendering the features in the correct order, it's just that that's not always the order I need!!! I have been looking at the Open Street Map site and noticed that they seem to have exactly the same problem so I'm assuming it's a limitation of the data at the moment.
I beg to disagree, using multiple feature types will work, let me
explain why. When you have multiple feature type styles in your SLD
each is rendered on a separate image in memory, and they are then merged onto a final image before sending back to the client.
If the "important roads" fts is specified _after_ the "smaller roads" fts, then the former will overwrite the latter, so it won't be possible
to have a "small" road overlap an important one, it will always be
the opposite.
Cheers
Andrea
Hi Andrea, Tom,
I've followed this conversation and thought it might help if I came in
as a third person.
Sometimes a minor road is bridged over a major road and sometimes the
major road is bridged over a minor road without there being an
intersection. To distinguish this on a map Tom wants to show the
appropriate line for a road on top. It is this which he is finding hard
to do.
Presumably there is an attribute in his roads data that helps
distinguish the actual layering of the roads. He does not always want
the same ordering e.g. Minor roads under major roads.
I don't know if that helps you understand each other. Sorry I don't have
a solution to offer.
Best wishes,
Andy
http://www.geog.leeds.ac.uk/people/a.turner/
-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net
[mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: 05 October 2007 11:36
To: Tom (JDi Solutions)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] styling help
Tom (JDi Solutions) ha scritto:
No, the sorted view approach does work, it's where the roads on the
map don't fit the rule that it doesn't work so setting up seperate
feature types won't make any difference. The renderer IS rendering
the features in the correct order, it's just that that's not always
the order I need!!! I have been looking at the Open Street Map site
and noticed that they seem to have exactly the same problem so I'm
assuming it's a limitation of the data at the moment.
I beg to disagree, using multiple feature types will work, let me
explain why. When you have multiple feature type styles in your SLD each
is rendered on a separate image in memory, and they are then merged onto
a final image before sending back to the client.
If the "important roads" fts is specified _after_ the "smaller roads"
fts, then the former will overwrite the latter, so it won't be possible
to have a "small" road overlap an important one, it will always be the
opposite.
Cheers
Andrea
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Thanks Andy, in the example I gave the orange road overlays the yellow road because it is the highest priority road. i.e. the renderer is rendering it in the correct order as I have specified it, it’s just that in this case I want them the other way around and I can’t work out how to do it without upsetting all the place where it is what I want elsewhere on the map. As far as I can tell there is no level in the data so we’re left to use rules which will be right more often than not and that’s what I’ve done. I’ve assumed that higher priority roads will always have precedence but that’s not always the case.
As I said before, it does look like Open Street Map’s own renderer has the same problem so I’m not too concerned about it and the obvious solution is to add a field to the data to determine the level, kind of like z-order in css, but since that’s not there I’ll just have to leave it for now.
On 10/5/07, Andy Turner <A.G.D.Turner@anonymised.com> wrote:
Hi Andrea, Tom,
I’ve followed this conversation and thought it might help if I came in
as a third person.
Sometimes a minor road is bridged over a major road and sometimes the
major road is bridged over a minor road without there being an
intersection. To distinguish this on a map Tom wants to show the
appropriate line for a road on top. It is this which he is finding hard
to do.
Presumably there is an attribute in his roads data that helps
distinguish the actual layering of the roads. He does not always want
the same ordering e.g. Minor roads under major roads.
I don’t know if that helps you understand each other. Sorry I don’t have
a solution to offer.
Best wishes,
Andy
http://www.geog.leeds.ac.uk/people/a.turner/
-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net
[mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of
Andrea Aime
Sent: 05 October 2007 11:36
To: Tom (JDi Solutions)
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] styling help
Tom (JDi Solutions) ha scritto:
No, the sorted view approach does work, it’s where the roads on the
map don’t fit the rule that it doesn’t work so setting up seperate
feature types won’t make any difference. The renderer IS rendering
the features in the correct order, it’s just that that’s not always
the order I need!!! I have been looking at the Open Street Map site
and noticed that they seem to have exactly the same problem so I’m
assuming it’s a limitation of the data at the moment.
I beg to disagree, using multiple feature types will work, let me
explain why. When you have multiple feature type styles in your SLD each
is rendered on a separate image in memory, and they are then merged onto
a final image before sending back to the client.
If the “important roads” fts is specified after the “smaller roads”
fts, then the former will overwrite the latter, so it won’t be possible
to have a “small” road overlap an important one, it will always be the
opposite.
Cheers
Andrea
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Tom (JDi Solutions) ha scritto:
Thanks Andy, in the example I gave the orange road overlays the yellow road because it is the highest priority road. i.e. the renderer is rendering it in the correct order as I have specified it, it's just that in this case I want them the other way around and I can't work out how to do it without upsetting all the place where it is what I want elsewhere on the map. As far as I can tell there is no level in the data so we're left to use rules which will be right more often than not and that's what I've done. I've assumed that higher priority roads will always have precedence but that's not always the case.
Aaahh.... sorry, my misunderstanding then. I'm still a little upside
down after two 9 hours jet lags in less than two weeks.
Sorry 
As I said before, it does look like Open Street Map's own renderer has the same problem so I'm not too concerned about it and the obvious solution is to add a field to the data to determine the level, kind of like z-order in css, but since that's not there I'll just have to leave it for now.
In fact I think SLD has no direct way to address this problem. If the
number of the hypotetical "z" variable is known, finite and small it
would be possible to address this by creating even more feature type styles, but otherwise I find this hard to handle.
I guess it would be interesting to have the possibility, in SLD, to
specify a "sortBy" clause so that you can say "sortBy zLevel, class"
and then use a single featureTypeStyle for the colored level.
Cheers
Andrea
That would indeed be useful and I’ve effectively mimicked it by sorting the view on which the feature type is based.
On 10/5/07, Andrea Aime < aaime@anonymised.com> wrote:
Tom (JDi Solutions) ha scritto:
Thanks Andy, in the example I gave the orange road overlays the yellow
road because it is the highest priority road. i.e. the renderer is
rendering it in the correct order as I have specified it, it’s just that
in this case I want them the other way around and I can’t work out how
to do it without upsetting all the place where it is what I want
elsewhere on the map. As far as I can tell there is no level in the
data so we’re left to use rules which will be right more often than not
and that’s what I’ve done. I’ve assumed that higher priority roads will
always have precedence but that’s not always the case.
Aaahh… sorry, my misunderstanding then. I’m still a little upside
down after two 9 hours jet lags in less than two weeks.
Sorry
As I said before, it does look like Open Street Map’s own renderer has
the same problem so I’m not too concerned about it and the obvious
solution is to add a field to the data to determine the level, kind of
like z-order in css, but since that’s not there I’ll just have to leave
it for now.
In fact I think SLD has no direct way to address this problem. If the
number of the hypotetical “z” variable is known, finite and small it
would be possible to address this by creating even more feature type
styles, but otherwise I find this hard to handle.
I guess it would be interesting to have the possibility, in SLD, to
specify a “sortBy” clause so that you can say “sortBy zLevel, class”
and then use a single featureTypeStyle for the colored level.
Cheers
Andrea