I am hitting a problem with the rendering of a MultiLineString (MLS) and hope someone can
1) Determine if it is a bug that should be reported, and
2) Provide any options for getting the desired result
The issue is simple - I have a MLS with three lines - A->B, A->C, and A->D
When rendered with the standard line SLD this manifests as a collection that include A->B, (B->A)**, A->C, (C->A)**, A->D, (D->A)**
where the items tagged with ** are straight lines between these points, and should not really be present in my opinion. Why is the rendering adding these 'end-to-start' connectors? Is there a way to tell it not to?
My current workaround is an overly complex SQL query that splits the MLS into its respective lines - so in this case the result is three rows with the respective individual Lines (and all other columns from the DB the same).
With out seeing the data and the sld it’s hard to say exactly, but it sounds as if you’ve used a PolygonSymbolizer instead of a LineSymbolizer to style the geometry.
It is using a LineSymbolizer. If needed I can post the SLD, a data sample, and some snapshots of the result.
On 4/29/2022 1:47 AM, Ian Turton wrote:
With out seeing the data and the sld it's hard to say exactly, but it sounds as if you've used a PolygonSymbolizer instead of a LineSymbolizer to style the geometry.
Given the behavior, I’m guessing you have multi-line string data in a database column
that’s declared to be LineString instead.
GeoServer follows a strict type system (based on its WFS heritage) and
will convert a MLS into a simple linestring in one of the possible ways, connecting the bits.
If that’s not the case, then yes, please do share a minimal data set to reproduce.
Cheers
Andrea
···
Regards,
Andrea Aime
==
GeoServer Professional Services from the experts!
Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
You nailed it (as usual), with one caveat. In the postgres DB the column type is geometry, but when I use the ‘Guess geometry type and srid’ from the SQL view for the layer, it is filling in the type as LineString. This is a bit odd since the table contains a mix of both LineString and MultiLineString entries. If I manually change it to geometry it reverts to rendering as expected.
So now the question is, is this misapplication of data type worthy of a bug report?
···
On 4/29/2022 11:22 PM, Andrea Aime wrote:
Given the behavior, I’m guessing you have multi-line string data in a database column
that’s declared to be LineString instead.
GeoServer follows a strict type system (based on its WFS heritage) and
will convert a MLS into a simple linestring in one of the possible ways, connecting the bits.
If that’s not the case, then yes, please do share a minimal data set to reproduce.
The guessing happens by loading a single record from the database. I guess it could try to use a few more records, but certainly not all of them (might take minutes or hours on very large tables).
I’d say it’s a possible minor improvement request, which we ask users to report only if they intend to back it with development time or funding (feature requests are otherwise closed after
one year of inactivity).
Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
Thanks. Not likely to get any support under my current contract. I’m not sure if there is an abstract SQL way to do this, but with postGIS something like
select st_geometryType(the_geom) as gts from xxx group by gts
should be reasonably quick. The good thing is that this is not a run time activity, so mildly slow performance should not be a big issue for most people.
···
On 5/11/2022 3:28 AM, Andrea Aime wrote:
The guessing happens by loading a single record from the database. I guess it could try to use a few more records, but certainly not all of them (might take minutes or hours on very large tables).
I’d say it’s a possible minor improvement request, which we ask users to report only if they intend to back it with development time or funding (feature requests are otherwise closed after
one year of inactivity).
