[Geoserver-users] One-way street directional arrows using SLD

Jordan_Anderson1 · January 23, 2009, 6:30pm

Hi all,

I searched the mailing list archives and may have missed the answer so
I apologize if someone has addressed this already, but has anyone
figured out a way to correctly print one-way arrows on streets? If so,
I'd be interested in hearing how you did it.

Thanks,
Jordan

Kris_Geusebroek · January 26, 2009, 7:01am

Hi Jordan,

If you know the angle in which the street is going you can use the
following code snippet in your TextSymbolizer of your SLD

<LabelPlacement>
  <PointPlacement>
    <Rotation>
      <ogc:Sub>
        <ogc:Literal>360.0</ogc:Literal>
        <ogc:PropertyName>ROTATION_ANGLE</ogc:PropertyName>
      </ogc:Sub>
    </Rotation>
  </PointPlacement>
</LabelPlacement>

Or something similar.
But you have to have a column in your database where the rotation angle
is specified this way.

Hope this is of use to you

Regards

Kris

-----Original Message-----
From: Jordan Anderson [mailto:jordandrsn@anonymised.com]
Sent: Friday, January 23, 2009 7:31 PM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] One-way street directional arrows using SLD

Hi all,

I searched the mailing list archives and may have missed the answer so
I apologize if someone has addressed this already, but has anyone
figured out a way to correctly print one-way arrows on streets? If so,
I'd be interested in hearing how you did it.

Thanks,
Jordan

------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jordan_Anderson1 · January 28, 2009, 4:20pm

Hi all,

I ended up using a slightly different approach to the one-way street
arrows and thought I'd share it.

New York City's street centerline file uses a field (trafdir) to
indicate one-way street segments. For one-way streets, it can be:
'W' - One-way in the direction of ascending street numbers ("with")
'A' - One-way in the opposite direction of ascending street numbers ("against")

I used text symbolizers (and the special characters that are built-in
to many fonts) to specify that labels should use a right arrow
character for streets with a 'W' and a left arrow character for
streets with an 'A'. Because the text symbolizer takes care of
aligning the font with the street, I didn't have to worry about
figuring out the proper rotation. (Using a single rotation for each
street segment is also a problem if you have curved streets and this
method solves that, too!)

Here's a snippet from the SLD (it's basically the same for both the A
and W case so I didn't include them both -- only the filter and hex
character literal differs):

<Rule>

  <ogc:Filter>
    <ogc:PropertyIsEqualTo>
      <ogc:PropertyName>trafdir</ogc:PropertyName>
        <ogc:Literal>W</ogc:Literal>
      </ogc:PropertyIsEqualTo>
  </ogc:Filter>

    <Font>
      <CssParameter name="font-family">Lucida Sans</CssParameter>
      <CssParameter name="font-style">Normal</CssParameter>
      <CssParameter name="font-size">18</CssParameter>
      <CssParameter name="font-weight">Normal</CssParameter>
    </Font>

</TextSymbolizer>
</Rule>

I've also attached a screen shot. Probably the most challenging thing
was getting the correct balance between street name labels and arrow
labels (which are on two different layers). I became intimately
familiar with all the new labeling options and made use of
spaceAround, maxDisplacement, and Repeat to get something close to the
right balance.

Thanks,
Jordan

On Mon, Jan 26, 2009 at 2:01 AM, Kris Geusebroek <kgeusebroek@anonymised.com> wrote:

Hi Jordan,

If you know the angle in which the street is going you can use the
following code snippet in your TextSymbolizer of your SLD

<LabelPlacement>
<PointPlacement>
   <Rotation>
     <ogc:Sub>
       <ogc:Literal>360.0</ogc:Literal>
       <ogc:PropertyName>ROTATION_ANGLE</ogc:PropertyName>
     </ogc:Sub>
   </Rotation>
</PointPlacement>
</LabelPlacement>

Or something similar.
But you have to have a column in your database where the rotation angle
is specified this way.

Hope this is of use to you

Regards

Kris

-----Original Message-----
From: Jordan Anderson [mailto:jordandrsn@anonymised.com]
Sent: Friday, January 23, 2009 7:31 PM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] One-way street directional arrows using SLD

Hi all,

I searched the mailing list archives and may have missed the answer so
I apologize if someone has addressed this already, but has anyone
figured out a way to correctly print one-way arrows on streets? If so,
I'd be interested in hearing how you did it.

Thanks,
Jordan

------------------------------------------------------------------------
------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Andrea_Aime3 · January 28, 2009, 4:26pm

Jordan Anderson ha scritto:

Hi all,

I ended up using a slightly different approach to the one-way street
arrows and thought I'd share it.

New York City's street centerline file uses a field (trafdir) to
indicate one-way street segments. For one-way streets, it can be:
'W' - One-way in the direction of ascending street numbers ("with")
'A' - One-way in the opposite direction of ascending street numbers ("against")

I used text symbolizers (and the special characters that are built-in
to many fonts) to specify that labels should use a right arrow
character for streets with a 'W' and a left arrow character for
streets with an 'A'. Because the text symbolizer takes care of
aligning the font with the street, I didn't have to worry about
figuring out the proper rotation. (Using a single rotation for each
street segment is also a problem if you have curved streets and this
method solves that, too!)

Here's a snippet from the SLD (it's basically the same for both the A
and W case so I didn't include them both -- only the filter and hex
character literal differs):

Wow, this looks very very nice, congratulations!
Thanks a lot for sharing the SLD.
Ah, for other users, I believe this trick will work only on 1.7.2
onwards (where label displacement is available and active)

Cheers
Andrea

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

Bjorn_Harrtell1 · January 29, 2009, 3:10pm

Looks nice but there is a problem with this method that I don't know
how to fix. The text symbolizer will always make the character read
from left to right. This affects one-way streets (non broken geometry)
that change direction between east and west...

Is there a way to override this behaviour? or any other ideas?

Using the new <VendorOption name="followLine">true</VendorOption>
doesn't help in this case afaik.

With regards,

/Björn Harrtell

On Wed, Jan 28, 2009 at 17:26, Andrea Aime <aaime@anonymised.com> wrote:

Jordan Anderson ha scritto:

Hi all,

I ended up using a slightly different approach to the one-way street
arrows and thought I'd share it.

New York City's street centerline file uses a field (trafdir) to
indicate one-way street segments. For one-way streets, it can be:
'W' - One-way in the direction of ascending street numbers ("with")
'A' - One-way in the opposite direction of ascending street numbers ("against")

I used text symbolizers (and the special characters that are built-in
to many fonts) to specify that labels should use a right arrow
character for streets with a 'W' and a left arrow character for
streets with an 'A'. Because the text symbolizer takes care of
aligning the font with the street, I didn't have to worry about
figuring out the proper rotation. (Using a single rotation for each
street segment is also a problem if you have curved streets and this
method solves that, too!)

Here's a snippet from the SLD (it's basically the same for both the A
and W case so I didn't include them both -- only the filter and hex
character literal differs):

Wow, this looks very very nice, congratulations!
Thanks a lot for sharing the SLD.
Ah, for other users, I believe this trick will work only on 1.7.2
onwards (where label displacement is available and active)

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jordan_Anderson1 · January 29, 2009, 3:45pm

Hi Bjoern,

If I understand your comment correctly, this does not affect the New
York data set because the streets are broken up by block. If a street
changes direction, there would be two adjacent records -- one with a
trafdir of 'A' and one with a trafdir of 'W'.

You're right that this technique would not work for a data set that
included single geometries that changed street direction in the middle
of a line.

I should mention that this method does depend on the geometry and the
trafdir field being consistent or else some of your streets will be
shown going one-way in the wrong direction. I'd say New York is about
90% consistent -- nothing that a little data cleanup won't resolve.

On Thu, Jan 29, 2009 at 10:10 AM, Björn Harrtell
<bjorn.harrtell@anonymised.com> wrote:

Looks nice but there is a problem with this method that I don't know
how to fix. The text symbolizer will always make the character read
from left to right. This affects one-way streets (non broken geometry)
that change direction between east and west...

Is there a way to override this behaviour? or any other ideas?

Using the new <VendorOption name="followLine">true</VendorOption>
doesn't help in this case afaik.

With regards,

/Björn Harrtell

On Wed, Jan 28, 2009 at 17:26, Andrea Aime <aaime@anonymised.com> wrote:

Jordan Anderson ha scritto:

Hi all,

I ended up using a slightly different approach to the one-way street
arrows and thought I'd share it.

New York City's street centerline file uses a field (trafdir) to
indicate one-way street segments. For one-way streets, it can be:
'W' - One-way in the direction of ascending street numbers ("with")
'A' - One-way in the opposite direction of ascending street numbers ("against")

I used text symbolizers (and the special characters that are built-in
to many fonts) to specify that labels should use a right arrow
character for streets with a 'W' and a left arrow character for
streets with an 'A'. Because the text symbolizer takes care of
aligning the font with the street, I didn't have to worry about
figuring out the proper rotation. (Using a single rotation for each
street segment is also a problem if you have curved streets and this
method solves that, too!)

Here's a snippet from the SLD (it's basically the same for both the A
and W case so I didn't include them both -- only the filter and hex
character literal differs):

Wow, this looks very very nice, congratulations!
Thanks a lot for sharing the SLD.
Ah, for other users, I believe this trick will work only on 1.7.2
onwards (where label displacement is available and active)

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Bjorn_Harrtell1 · January 30, 2009, 8:25am

Yes with some data cleaning and correct use of trafdir the textsymbol
arrows would work.. but imagine if you need to do that cleanup
nationwide.. So I'm still looking for a way to display directional
arrows that follows the geometry regardless.

/Björn

On Thu, Jan 29, 2009 at 16:45, Jordan Anderson <jordandrsn@anonymised.com> wrote:

Hi Bjoern,

If I understand your comment correctly, this does not affect the New
York data set because the streets are broken up by block. If a street
changes direction, there would be two adjacent records -- one with a
trafdir of 'A' and one with a trafdir of 'W'.

You're right that this technique would not work for a data set that
included single geometries that changed street direction in the middle
of a line.

I should mention that this method does depend on the geometry and the
trafdir field being consistent or else some of your streets will be
shown going one-way in the wrong direction. I'd say New York is about
90% consistent -- nothing that a little data cleanup won't resolve.

On Thu, Jan 29, 2009 at 10:10 AM, Björn Harrtell
<bjorn.harrtell@anonymised.com> wrote:

Looks nice but there is a problem with this method that I don't know
how to fix. The text symbolizer will always make the character read
from left to right. This affects one-way streets (non broken geometry)
that change direction between east and west...

Is there a way to override this behaviour? or any other ideas?

Using the new <VendorOption name="followLine">true</VendorOption>
doesn't help in this case afaik.

With regards,

/Björn Harrtell

On Wed, Jan 28, 2009 at 17:26, Andrea Aime <aaime@anonymised.com> wrote:

Jordan Anderson ha scritto:

Hi all,

I ended up using a slightly different approach to the one-way street
arrows and thought I'd share it.

New York City's street centerline file uses a field (trafdir) to
indicate one-way street segments. For one-way streets, it can be:
'W' - One-way in the direction of ascending street numbers ("with")
'A' - One-way in the opposite direction of ascending street numbers ("against")

I used text symbolizers (and the special characters that are built-in
to many fonts) to specify that labels should use a right arrow
character for streets with a 'W' and a left arrow character for
streets with an 'A'. Because the text symbolizer takes care of
aligning the font with the street, I didn't have to worry about
figuring out the proper rotation. (Using a single rotation for each
street segment is also a problem if you have curved streets and this
method solves that, too!)

Here's a snippet from the SLD (it's basically the same for both the A
and W case so I didn't include them both -- only the filter and hex
character literal differs):

Wow, this looks very very nice, congratulations!
Thanks a lot for sharing the SLD.
Ah, for other users, I believe this trick will work only on 1.7.2
onwards (where label displacement is available and active)

Cheers
Andrea

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Andrea_Aime3 · January 30, 2009, 9:20am

Björn Harrtell ha scritto:

Yes with some data cleaning and correct use of trafdir the textsymbol
arrows would work.. but imagine if you need to do that cleanup
nationwide.. So I'm still looking for a way to display directional
arrows that follows the geometry regardless.

I've been thinking about this a little. As you noticed, GeoServer
tries to keep the text "looking up" and does not really know
that you used a symbol that does not have a natural reading direction,
so it flips it up if the "up" of the character is looking down.

Yet, we could introduce an extra vendor parameter that disables
this behaviour, something like:

<VendorOption name="flipText">false</VendorOption>

and in this case the symbol would just follow the line direction.
If you think this could solve your problem, please file a new
feature request at jira.codehaus.org.
And oh, feel free to suggest a different name for the option,
I'm generally not that good with names.

Cheers
Andrea

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

Bjorn_Harrtell1 · January 30, 2009, 9:38am

Created GEOS-2601. I think it would be a great feature that will be
very useful for us at least.

The name isn't that bad I suggested another name too but flipText
might actually be more fitting.

/Björn

On Fri, Jan 30, 2009 at 10:20, Andrea Aime <aaime@anonymised.com> wrote:

Björn Harrtell ha scritto:

Yes with some data cleaning and correct use of trafdir the textsymbol
arrows would work.. but imagine if you need to do that cleanup
nationwide.. So I'm still looking for a way to display directional
arrows that follows the geometry regardless.

I've been thinking about this a little. As you noticed, GeoServer
tries to keep the text "looking up" and does not really know
that you used a symbol that does not have a natural reading direction,
so it flips it up if the "up" of the character is looking down.

Yet, we could introduce an extra vendor parameter that disables
this behaviour, something like:

<VendorOption name="flipText">false</VendorOption>

and in this case the symbol would just follow the line direction.
If you think this could solve your problem, please file a new
feature request at jira.codehaus.org.
And oh, feel free to suggest a different name for the option,
I'm generally not that good with names.

Cheers
Andrea

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

David_R_Robison1 · August 6, 2009, 3:29pm

I have a geoserver instance that contains a collection of layers. What I would like to do is create a BaseMapGroup that includes those layers and some GIS imagery from another WMS (for example, a USGS server). Is this possible? Thanks, David

--

David R Robison
Open Roads Consulting, Inc.
103 Watson Road, Chesapeake, VA 23320
phone: (757) 546-3401
e-mail: drrobison@anonymised.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/book_detail.php?id=2579

Andrea_Aime3 · August 6, 2009, 4:10pm

David R Robison ha scritto:

I have a geoserver instance that contains a collection of layers. What I would like to do is create a BaseMapGroup that includes those layers and some GIS imagery from another WMS (for example, a USGS server). Is this possible? Thanks, David

Nope, not possible, GeoServer does not support WMS cascading at all
unfortunately.
We could try to add that functionality to trunk where we have a new
config subsystem, but it would not be a quick one to add I fear.
Or we could setup remote WMS layers as coverages (they are georeferenced
images of sort, in that the location and srs of the image are known
by the request one makes) thought it would be quite an odd setup.

A base map group is usually best served from a tile cache, I heard
through the gravepine that GWC has in the roadmap just the ability
to combine images coming from different servers.

Arne also tells me tilecache is able to do the above already.

Cheers
Andrea

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