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 > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
