On 12/20/2011 08:45 AM, Peter Wendorff wrote: > Hi. > I'm working on the look-and-listen-map (toolserver project lalm), a web > map portal for the Blind and Visually Impaired. > That is not a rendering application like the several mapnik stylesheets > running on the toolserver, but I agreed with the Admins, that it might > be worth in respect of capacities of the toolserver to use the mapnik > style nevertheless. > > Today I finally got database access and looked deeper into the schema. > Most queries in my application rely on the osm_id present in all tables > (and index, too), so that's not a problem. > Some queries will later on require geometric queries, but here I can > combine the postprocessed tables (planet_nodes, planet_line, > planet_polygon...) for filtering and the non-processed ones for fetching > the values - so that's okay, too. > > My problem lies, where mapnik does ugly tricks for rendering: I have a > node-id and want to get all ways this node is part of. > > That would be possible, querying planet_ways, as planet_ways contains a > field nodes, that is a integer-array; but as far as I know there is no > performant way to query an array-field of a database on containing a > particular element. > > Currently my code is based on a different database schema, but I have a > query with the following characteristics, that I need with the > osm_mapnik-scheme: > > IN: node_id (int) > OUT: a list of way_id, where the corresponding way contains the node > with id node_id.
The mapnik updater has to do that as well. As a moved node needs to recreate the geometry of the way that contains that node. There is a GIN index on the planet_ways table that allows to do this. The query osm2pgsql runs for this is "UPDATE %p_ways SET pending = true WHERE nodes && ARRAY[$1] AND NOT pending;" You don't want the update or pending part, but the "WHERE nodes && ARRAY[osm_id]" should work for you. > > A second question would be, if errors would occur, when I combine e.g. > planet_ways with planet_line in a query, and a matching row in > planet_ways is pending. Usually the intermediate tables are only > accessed by the import tool, so I would do unconventional things here, > but am I right? If the planet_ways-row is pending, the data of this > table is not in sync with the data in planet_line. Yes, that is correct. But that should only be for a fairly short period of time. Kai > > regards > Peter > > > _______________________________________________ > Maps-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/maps-l _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l
