[Geoserver-users] Duplicate city labels on the wrong feature

My city shape .dbf file has duplicate entries for some cities. The lonlat data is the same, but when rendered, the extra label is given to a nearby city. I am running 1.5.1. Is this a known bug with a work around or do I need to clean up the data?

Thanks,

Al

Geoserver is trying to space out the labels. So if two are on top of
each other, they both will be moved slightly, or one more-so, in such
a way that both are visible and not overlapping.

I believe it is possible to style the labels in SLD so that they do
not spread themselves out, but I can't remember the exact parameter to
do so. some of the example SLDs that come with GeoServer may shed some
light.
Is it an option for you to remove the duplicate cities?

cheers,

On 7/25/07, Al Byers <byersa@anonymised.com> wrote:

My city shape .dbf file has duplicate entries for some cities. The lonlat
data is the same, but when rendered, the extra label is given to a nearby
city. I am running 1.5.1. Is this a known bug with a work around or do I
need to clean up the data?

Thanks,

Al

-------------------------------------------------------------------------
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

--
Brent Owens

Brent,

Thanks for responding, but in this case I have two different cities labeled “Gallup City” - one of them is the wrong city. I don’t think this is the same condition that you are referring to. Let me know if I am mistaken.

Thanks,

-Al

On 7/25/07, Brent Owens <brentowens@anonymised.com> wrote:

Geoserver is trying to space out the labels. So if two are on top of
each other, they both will be moved slightly, or one more-so, in such
a way that both are visible and not overlapping.

I believe it is possible to style the labels in SLD so that they do
not spread themselves out, but I can’t remember the exact parameter to
do so. some of the example SLDs that come with GeoServer may shed some
light.
Is it an option for you to remove the duplicate cities?

cheers,

On 7/25/07, Al Byers <byersa@anonymised.com> wrote:

My city shape .dbf file has duplicate entries for some cities. The lonlat
data is the same, but when rendered, the extra label is given to a nearby
city. I am running 1.5.1. Is this a known bug with a work around or do I
need to clean up the data?

Thanks,

Al


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


Brent Owens

Hmmm... strange one... Could you perhaps send us a screen snapshot? The attributes of teh points in question could be useful as well.

-Justin

Al Byers wrote:

Brent,

Thanks for responding, but in this case I have two different cities labeled "Gallup City" - one of them is the wrong city. I don't think this is the same condition that you are referring to. Let me know if I am mistaken.

Thanks,

-Al

On 7/25/07, *Brent Owens* <brentowens@anonymised.com <mailto:brentowens@anonymised.com>> wrote:

    Geoserver is trying to space out the labels. So if two are on top of
    each other, they both will be moved slightly, or one more-so, in such
    a way that both are visible and not overlapping.

    I believe it is possible to style the labels in SLD so that they do
    not spread themselves out, but I can't remember the exact parameter to
    do so. some of the example SLDs that come with GeoServer may shed some
    light.
    Is it an option for you to remove the duplicate cities?

    cheers,

    On 7/25/07, Al Byers <byersa@anonymised.com
    <mailto:byersa@anonymised.com>> wrote:
     > My city shape .dbf file has duplicate entries for some cities.
    The lonlat
     > data is the same, but when rendered, the extra label is given to
    a nearby
     > city. I am running 1.5.1. Is this a known bug with a work around
    or do I
     > need to clean up the data?
     >
     > Thanks,
     >
     > Al
     >
    -------------------------------------------------------------------------
     > 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
    <mailto:Geoserver-users@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/geoserver-users
     >

    --
    Brent Owens

------------------------------------------------------------------------

-------------------------------------------------------------------------
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

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

Justin,

I have included a screen shot and shot of the attributes. I have also include the data from the two “duplicate” fields (Albuquerque city) in the DBF file. There is a third actually.

As I prepared this, I got to thinking that what this all shows is that the .SHP file has 3 entries for “Albuquerque city” - would that be the case? I don’t know how to inspect the geometry field except to render it. In this case, it looks like a data error.

Am I reading this right? I got the data directly from the New Mexico GIS site, http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns

0 0.03 106 51 2000 35 02000 Albuquerque city NM 384736 166870 342409 1631 +35.117218 -106.624636
0.04 3.21 107 1 2000 35 02000 Albuquerque city NM 384736 166870 342409 1631 +35.117218 -106.624636

Let me know if there is more data or more that I need to do.

Thanks,
-Al

PS You can see why I need the string replace feature - to eliminate “city” and “CDP”.

On 7/25/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hmmm… strange one… Could you perhaps send us a screen snapshot? The
attributes of teh points in question could be useful as well.

-Justin

Picture 1.png

Picture 4.png

Hi Al,

Am I reading this right? I got the data directly from the New Mexico GIS site, http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns

Which file in particular is it. I will download it and take a look at the data directly.

0 0.03 106 51 2000 35 02000 Albuquerque city NM 384736 166870 342409 1631 +35.117218 -106.624636
                                                                        
                                      0.04 3.21 107 1 2000 35 02000 Albuquerque city NM 384736 166870 342409 1631 +35.117218 -106.624636

Let me know if there is more data or more that I need to do.

Thanks,
-Al

PS You can see why I need the string replace feature - to eliminate "city" and "CDP".
                                                                  
On 7/25/07, *Justin Deoliveira* <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

    Hmmm... strange one... Could you perhaps send us a screen snapshot? The
    attributes of teh points in question could be useful as well.

    -Justin

!DSPAM:4007,46a7ef36214005210051143!
------------------------------------------------------------------------

------------------------------------------------------------------------

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

Justin,

It has the title of “GPS Roads” on this url: http://rgis.unm.edu/loader_div.cfm?theme=Transportation&subtheme=&groupname=&quicknav=page&searchletter=a&maxrows=100&start=1&extent=&new=false&x=13&y=12

I am also finding that as I get down to the higher resolutions, the performance really tanks as it tries to display streets. I am using the indexed shapefile datasets. Is this a problem that could most likely be solved by going to PostGIS?

Thanks,

-Al

On 7/26/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Al,

Am I reading this right? I got the data directly from the New Mexico GIS
site, http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns

Which file in particular is it. I will download it and take a look at
the data directly.

0 0.03 106 51 2000 35 02000 Albuquerque city
NM 384736 166870 342409 1631 +35.117218
-106.624636

0.04 3.21 107 1 2000 35 02000 Albuquerque city
NM 384736 166870 342409 1631 +35.117218
-106.624636

Let me know if there is more data or more that I need to do.

Thanks,
-Al

PS You can see why I need the string replace feature - to eliminate
“city” and “CDP”.

On 7/25/07, Justin Deoliveira <jdeolive@anonymised.com
mailto:[jdeolive@anonymised.com](mailto:jdeolive@anonymised.com)> wrote:

Hmmm… strange one… Could you perhaps send us a screen snapshot? The
attributes of teh points in question could be useful as well.

-Justin

!DSPAM:4007,46a7ef36214005210051143!



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

Hi Al,

Somewhat confused... I thought it was the point/city dataset you were having the problem with?

About the performance... postgis might help but doubtful. I see only about 12000 features in that shapefile... should be pretty snappy with indexed shapefile as well.

Do you have scale dependent styles which engage at the higher resolutions? Could be the style that is causing the performance hit.

-Justin

Al Byers wrote:

Justin,

It has the title of "GPS Roads" on this url: http://rgis.unm.edu/loader_div.cfm?theme=Transportation&subtheme=&groupname=&quicknav=page&searchletter=a&maxrows=100&start=1&extent=&new=false&x=13&y=12

I am also finding that as I get down to the higher resolutions, the performance really tanks as it tries to display streets. I am using the indexed shapefile datasets. Is this a problem that could most likely be solved by going to PostGIS?

Thanks,

-Al

On 7/26/07, *Justin Deoliveira* <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

    Hi Al,

     > Am I reading this right? I got the data directly from the New
    Mexico GIS
     > site,
    http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns
    <http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns&gt;

    Which file in particular is it. I will download it and take a look at
    the data directly.
     >
     > 0 0.03 106 51 2000 35 02000 Albuquerque city
     > NM 384736 166870 342409 1631 +35.117218
     > -106.624636
     >
     > 0.04 3.21 107 1 2000 35 02000 Albuquerque city
     > NM 384736 166870 342409 1631 +35.117218
     > -106.624636
     >
     > Let me know if there is more data or more that I need to do.
     >
     > Thanks,
     > -Al
     >
     > PS You can see why I need the string replace feature - to eliminate
     > "city" and "CDP".
     >
     > On 7/25/07, *Justin Deoliveira* <jdeolive@anonymised.com
    <mailto:jdeolive@anonymised.com>
     > <mailto:jdeolive@anonymised.com>>
    wrote:
     >
     > Hmmm... strange one... Could you perhaps send us a screen
    snapshot? The
     > attributes of teh points in question could be useful as well.
     >
     > -Justin
     >
    ------------------------------------------------------------------------
     >
    ------------------------------------------------------------------------
     >

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

!DSPAM:4007,46a8c6ff23326491211187!

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

Sorry Justin,

I just spaced it. I had this performance problem on my mind.
The right url is: http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns
It is the row titled: Metro Boundary of Towns >5000. The file is cit2shp.zip

Regarding the performance issue. I do have resolution dependent styles. What are the things in a style that slow it down the most?
TextSymbolizer?
Functions?
Multiple overlays?

Still, like you said, it would seem odd that 12,000 features would slow down an indexed shapefile.

Thanks for all your help.
-Al

On 7/26/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Al,

Somewhat confused… I thought it was the point/city dataset you were
having the problem with?

About the performance… postgis might help but doubtful. I see only
about 12000 features in that shapefile… should be pretty snappy with
indexed shapefile as well.

Do you have scale dependent styles which engage at the higher
resolutions? Could be the style that is causing the performance hit.

-Justin

Justin,

Sorry to bother you on the performance issue. Somehow, multiple FeatureTypeStyle elements crept back into my SLD and that seems to be the kiss of death.

-Al

On 7/26/07, Al Byers <byersa@anonymised.com> wrote:

Sorry Justin,

I just spaced it. I had this performance problem on my mind.
The right url is: http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns
It is the row titled: Metro Boundary of Towns >5000. The file is cit2shp.zip

Regarding the performance issue. I do have resolution dependent styles. What are the things in a style that slow it down the most?
TextSymbolizer?
Functions?
Multiple overlays?

Still, like you said, it would seem odd that 12,000 features would slow down an indexed shapefile.

Thanks for all your help.
-Al

On 7/26/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Al,

Somewhat confused… I thought it was the point/city dataset you were
having the problem with?

About the performance… postgis might help but doubtful. I see only
about 12000 features in that shapefile… should be pretty snappy with
indexed shapefile as well.

Do you have scale dependent styles which engage at the higher
resolutions? Could be the style that is causing the performance hit.

-Justin

Hi Al,

So I downloaded the data and the more I look at it the more I think that Brents initial explanation is correct. Its just that GeoServer is positioning the labels in a way so that they do not collide with each other.

I also noted that are are many points with duplicate names. For instance i noted 17 points with the name "Albuquerque city" and 2 named "Gallup city". And many which have no names... this in conjunction with the label collision stuff is probably what is leading to the strange labeling stuff.

SLD has support for label placement strategies. You can try playing around with those and see if it helps.

-Justin

Al Byers wrote:

Sorry Justin,

I just spaced it. I had this performance problem on my mind.
The right url is: http://rgis.unm.edu/loader_div.cfm?theme=Cities%20and%20Towns
It is the row titled: Metro Boundary of Towns >5000. The file is cit2shp.zip

Regarding the performance issue. I do have resolution dependent styles. What are the things in a style that slow it down the most?
TextSymbolizer?
Functions?
Multiple overlays?

Still, like you said, it would seem odd that 12,000 features would slow down an indexed shapefile.

Thanks for all your help.
-Al

On 7/26/07, *Justin Deoliveira* <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

    Hi Al,

    Somewhat confused... I thought it was the point/city dataset you were
    having the problem with?

    About the performance... postgis might help but doubtful. I see only
    about 12000 features in that shapefile... should be pretty snappy with
    indexed shapefile as well.

    Do you have scale dependent styles which engage at the higher
    resolutions? Could be the style that is causing the performance hit.

    -Justin

!DSPAM:4007,46a8da8d55021804284693!

------------------------------------------------------------------------

-------------------------------------------------------------------------
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/

!DSPAM:4007,46a8da8d55021804284693!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46a8da8d55021804284693!

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

Justin Deoliveira ha scritto:

Hi Al,

So I downloaded the data and the more I look at it the more I think that Brents initial explanation is correct. Its just that GeoServer is positioning the labels in a way so that they do not collide with each other.

I also noted that are are many points with duplicate names. For instance i noted 17 points with the name "Albuquerque city" and 2 named "Gallup city". And many which have no names... this in conjunction with the label collision stuff is probably what is leading to the strange labeling stuff.

SLD has support for label placement strategies. You can try playing around with those and see if it helps.

Dave introduced label grouping features to deal with multiple features
having the same label. It's a non standard SLD extension, but we're using it in our Sigma demo so it should be working ok.

More docs here: http://docs.codehaus.org/display/GEOSDOC/LabelingOptions

Cheers
Andrea