I saw in the IRC logs today that the developers noticed Google's KML size limitations. We've been getting bitten by this too. Would some sort of administrator-tunable line simplification approach to reduce the number of vertices be able to be implemented in geoserver to reduce KML file sizes?
jcz@anonymised.com ha scritto:
I saw in the IRC logs today that the developers noticed Google's KML
size limitations. We've been getting bitten by this too. Would some
sort of administrator-tunable line simplification approach to reduce
the number of vertices be able to be implemented in geoserver to
reduce KML file sizes?
Yeah, that could be an option. Another one would be to reduce
the number of decimals used to express coordinates, now
hard coded to 5.
I'm just wondering, would this be a one for all setting (affecting
every KML request the same way) or would it be better to have
a specific GetMap vendor parameter that could drive the simplification
differently on each request?
In a separate mail in this mailing list we're just discussing the
possibility to give each output format a set of options to be
specified with a vendor parameter in GetMap, and this could be one.
Cheers
Andrea
Having an option to actually do a line simplification ( like a
douglas-peucker ) is an interesting idea. Seems almost WPS like, and
would not really be specific to kml. Pretty sure there is code in JTS
that does this as well.
Andrea Aime wrote:
jcz@anonymised.com ha scritto:
I saw in the IRC logs today that the developers noticed Google's KML
size limitations. We've been getting bitten by this too. Would some
sort of administrator-tunable line simplification approach to reduce
the number of vertices be able to be implemented in geoserver to
reduce KML file sizes?Yeah, that could be an option. Another one would be to reduce
the number of decimals used to express coordinates, now
hard coded to 5.
I'm just wondering, would this be a one for all setting (affecting
every KML request the same way) or would it be better to have
a specific GetMap vendor parameter that could drive the simplification
differently on each request?
In a separate mail in this mailing list we're just discussing the
possibility to give each output format a set of options to be
specified with a vendor parameter in GetMap, and this could be one.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,465fc42112881030819293!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Indeed there is code in JTS to do it: for line features and isolated polygons it works great.
The big problem is that for adjacent polygons sharing edges the common edges will be generalised differently for each polygon. You can't (easily, to the best of my knowledge) do a proper topologically-aware simplification, so you end up with a bunch of not-quite-meeting and/or overlapping polygons.
May be worth offering as an option, but would definitely need to be able to turn it off (for given layers?) if the generalisation wasn't appropriate for the data, and maybe look at getting all the polygons into a graph and simplifying each edge and then rebuilding the polygons from that (probably a fair bit of work).
Hope that's helpful!
Edward
/crawls back under rock
Justin Deoliveira wrote:
Having an option to actually do a line simplification ( like a
douglas-peucker ) is an interesting idea. Seems almost WPS like, and
would not really be specific to kml. Pretty sure there is code in JTS
that does this as well.Andrea Aime wrote:
jcz@anonymised.com ha scritto:
I saw in the IRC logs today that the developers noticed Google's KML
size limitations. We've been getting bitten by this too. Would some
sort of administrator-tunable line simplification approach to reduce
the number of vertices be able to be implemented in geoserver to
reduce KML file sizes?Yeah, that could be an option. Another one would be to reduce
the number of decimals used to express coordinates, now
hard coded to 5.
I'm just wondering, would this be a one for all setting (affecting
every KML request the same way) or would it be better to have
a specific GetMap vendor parameter that could drive the simplification
differently on each request?
In a separate mail in this mailing list we're just discussing the
possibility to give each output format a set of options to be
specified with a vendor parameter in GetMap, and this could be one.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,465fc42112881030819293!
Edward Nash ha scritto:
Indeed there is code in JTS to do it: for line features and isolated polygons it works great.
The big problem is that for adjacent polygons sharing edges the common edges will be generalised differently for each polygon. You can't (easily, to the best of my knowledge) do a proper topologically-aware simplification, so you end up with a bunch of not-quite-meeting and/or overlapping polygons.
Yeah, that would be bad for KML.
May be worth offering as an option, but would definitely need to be able to turn it off (for given layers?) if the generalisation wasn't appropriate for the data, and maybe look at getting all the polygons into a graph and simplifying each edge and then rebuilding the polygons from that (probably a fair bit of work).
That would be too much work to do on the fly, it would have to be done
off line, just once, for selected scale ranges.
It's a teqnique we have applied with success for WMS layers, in this
case we just siplified since if you're careful the messed topology
cannot be seen: you create multiple geom colums at various generalization levels, and have an SLD that picks the right column
depending on the map scale. The speed up is quite visible.
Cheers
Andrea