[osmosis-dev] Problem with --node-key-value
Hi, i am new here so sorry if i mail to the wrong place. I wanted an osm file with all places=* so city, town etc. But i am getting an empty out.osm. What am i donig wrong? With ways (--way-key-value) this works great. terminal command: osmosis --read-xml in.osm --node-key-value keyValueList=place.city,place.town,place.village,place.hamlet,place.suburb --used-node idTrackerType=BitSet --write-xml out.osm out.osm: ?xml version='1.0' encoding='UTF-8'? osm version=0.6 generator=Osmosis 0.36 bound box=49.39089,7.76757,51.66252,10.24398 origin=0.37-SNAPSHOT/ /osm regards faulerflex -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Osmosis 0.37 Released
On Sat, Oct 16, 2010 at 9:41 PM, Jochen Topf joc...@remote.org wrote: On Sat, Oct 16, 2010 at 05:33:37PM +1100, Brett Henderson wrote: - Updated the pgsql schema (now version 6) to move all tags into hstore columns, add a ways.nodes column and CLUSTER the nodes and ways tables. Significant performance increases. Is there some magic involved or do you just call CLUSTER after the import? When I tested CLUSTER it helped with reads, but creating the cluster was very expensive. No magic unfortunately. The CLUSTER step is the most expensive part of the process because it changes the location on disk of every record in the database. It took several days for a full planet when I tested it out. I was performing bbox queries (similar ROMA or TRAPI but with my implementation that uses true way geometries instead of just node locations) and 1x1 degree queries for heavily populated areas (eg. Munich, London) were taking up to an hour to perform. After removing tags tables and performing CLUSTER statements the time reduced to somewhere between 5 and 10 minutes due to much reduced disk seeking. The database is kept up to date with hourly diffs so the CLUSTER step only has to be performed once (or once every few months perhaps) but the read benefits are ongoing. If you're performing regular full imports it may not make sense. If the overhead of performing the CLUSTER step outweighs the read benefits (depends on the lifetime of your database) then you can skip the CLUSTER step. It makes no functional difference that I'm aware of. Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] lost relations while clipping
Hi Maxim, 2010/10/12 Maxim Dubinin s...@gis-lab.info Hi osmosis-devs, On our regional extraction system we've ran into what seems to be a bug. Relations, that are members by themselves are dropped while extracting. Example of such relation: http://www.openstreetmap.org/browse/relation/358215 Code and example to reproduce this behavior is attached. Thanks for the detailed example, it makes it much easier to diagnose your issue. The reason for the dropped relation is a limitation of how Osmosis performs bounding-box/bounding-polygon processing. Osmosis processes all data in a stream. First it processes all nodes one by one and keeps track of which nodes are in the bounding box. It then processes each way one by one and uses the node list to determine which ways are in the bounding box. Then it processes the relations one by one and uses the list of nodes, ways, and already selected relations to determine if a relation is in the bounding box. In your example, relation 795 is processed first and contains relation 792. But 792 hasn't been processed (in your example, the two ids are out of order) yet so Osmosis doesn't know that it will be inside the bounding box and ignores it. It then processes 792 which has two ways inside the bounding box so it includes that relation. But it never goes back to include relation 795 because it has forgotten about it. In your example, if you switched the order of relation 792 and 795 then 795 *would* get included. The only way to avoid this limitation is to replace your existing --bp step: --bp file=test.poly with --bp file=test.poly completeWays=yes completeRelations=yes This makes Osmosis run *much* slower and might not be acceptable. With those options enabled, it builds temporary stores of nodes, ways and relations so that it can go back and randomly access data. But the temporary data stores are quite slow which has a very large impact on performance. Hope that helps. Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Problem with --node-key-value
I've just taken a look at the code (I didn't write these tasks) for the --node-key-value task and it works slightly differently to the --way-key-value task. The --way-key-value task passes through node and relation objects unchanged, but the --node-key-value task drops them. That means that when you have a --node-key-value task followed by a --used-node task you are going to drop everything. Note that it doesn't make sense to use the --used-node task in this case anyway because place nodes will typically not be part of a way. So two suggestions: 1. Remove the --used-node task. 2. Use the --tag-filter task instead which is much more flexible. Cheers, Brett On Sun, Oct 17, 2010 at 1:15 AM, Flex Fauler faulerf...@gmx.de wrote: Hi, i am new here so sorry if i mail to the wrong place. I wanted an osm file with all places=* so city, town etc. But i am getting an empty out.osm. What am i donig wrong? With ways (--way-key-value) this works great. terminal command: osmosis --read-xml in.osm --node-key-value keyValueList=place.city,place.town,place.village,place.hamlet,place.suburb --used-node idTrackerType=BitSet --write-xml out.osm out.osm: ?xml version='1.0' encoding='UTF-8'? osm version=0.6 generator=Osmosis 0.36 bound box=49.39089,7.76757,51.66252,10.24398 origin=0.37-SNAPSHOT/ /osm regards faulerflex -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
