It is currently unclear how to proceed on the valid KML issue. The issue can be summed up in this jira issue:
http://jira.codehaus.org/browse/GEOS-2447
But basically it boils down to that with the patch as written, we can't generate KML from datastores which do not provide reliable fids. The most common case of this is a db table with a primary key.
However i am told from arne that if we do not produce valid KML then there are issues with GeoSearch.
Dwins came up with the idea to use a temp file approach. David can you expand on this? I am not 100% sure what the plan is there.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
It is currently unclear how to proceed on the valid KML issue. The issue can be summed up in this jira issue:
http://jira.codehaus.org/browse/GEOS-2447
But basically it boils down to that with the patch as written, we can't generate KML from datastores which do not provide reliable fids. The most common case of this is a db table with a primary key.
However i am told from arne that if we do not produce valid KML then there are issues with GeoSearch.
Dwins came up with the idea to use a temp file approach. David can you expand on this? I am not 100% sure what the plan is there.
I would like to throw in one detail. For most maps it's not like
we really need to generate a style per feature. If all the styles
are attribute independent, we actually need just to generate
a proper combination of them based on the existing rules and
feature type styles (the possible combinations on how the
filters and the like make them up).
Yet you're right, if a style is dynamic, that is, actually
depends on feature attributes, then we need a style per feature,
and that may require a double scan.
Wondering if assuming the iteration order will be the same is
too much... it will break if a transaction occurs between
the two scans.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
The idea I had regarding a temp file was to do the encoding the same way that we used to; with the styles and placemarks being generated in parallel. However, rather than encoding them both to the same stream, we'd send the styles directly to the http output stream and dump the placemarks to a temporary file. When styles for all the features had been encoded, we'd just read the temporary file and dump its contents to the http output stream, then close up as normal.
Having actually started to attempt this approach, I've realized that's it's not entirely trivial to encode xml to two separate streams in the current encoder architecture, but I stopped looking into it when this issue came up on the mailing list to wait and see how this discussion played out.
Another possibility that I discussed with Arne goes along the lines of what Andrea mentioned, where we just have some reliable way of referring to a specific style and then reuse the same <Style> from the KML for multiple placemarks rendered with the same look. Going a step further, we could even extract these styles to a separate document, which would reduce the needed bandwidth considerably for regionated datasets consisting of many documents with a small number of features in each one.
-David Winslow
Andrea Aime wrote:
Justin Deoliveira ha scritto:
It is currently unclear how to proceed on the valid KML issue. The issue can be summed up in this jira issue:
http://jira.codehaus.org/browse/GEOS-2447
But basically it boils down to that with the patch as written, we can't generate KML from datastores which do not provide reliable fids. The most common case of this is a db table with a primary key.
However i am told from arne that if we do not produce valid KML then there are issues with GeoSearch.
Dwins came up with the idea to use a temp file approach. David can you expand on this? I am not 100% sure what the plan is there.
I would like to throw in one detail. For most maps it's not like
we really need to generate a style per feature. If all the styles
are attribute independent, we actually need just to generate
a proper combination of them based on the existing rules and
feature type styles (the possible combinations on how the
filters and the like make them up).
Yet you're right, if a style is dynamic, that is, actually
depends on feature attributes, then we need a style per feature,
and that may require a double scan.
Wondering if assuming the iteration order will be the same is
too much... it will break if a transaction occurs between
the two scans.
Cheers
Andrea
For right now I don't think we need to get in valid KML. Since we're going to defer emphasis on the geosearch stuff the main client for KML still is Google Earth. In the future that will change, and we'll work to improve it. But for now generating KML from things without fids is more important than valid KML, imho.
C
Justin Deoliveira wrote:
It is currently unclear how to proceed on the valid KML issue. The issue can be summed up in this jira issue:
http://jira.codehaus.org/browse/GEOS-2447
But basically it boils down to that with the patch as written, we can't generate KML from datastores which do not provide reliable fids. The most common case of this is a db table with a primary key.
However i am told from arne that if we do not produce valid KML then there are issues with GeoSearch.
Dwins came up with the idea to use a temp file approach. David can you expand on this? I am not 100% sure what the plan is there.
-Justin
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.