Laut der brandneuen Wikiseite http://wiki.openstreetmap.org/wiki/64-bit_Identifiers lassen sich OSM-Daten, die 64bit-IDs enthalten, nicht mehr mit osmosis filtern; stattdessen wird vorgeschlagen, osmconvert zu verwenden.
Alles klar, ich habe also mein Kandidatensuchskript mal eben von osmosis auf osmconvert umgestellt (warum auch nicht, soll ja eh schneller sein) - nur um festzustellen, daß diesem das verwendete Filterpolygon zu groß ist 
Also zurück zu osmosis. Ich habe die Filterfunktion mit den bekannten 64bit-Testdaten und “meinem” (will sagen: aighes’) Deutschland-Filterpolygon ausprobiert: einmal mit den Originaldaten (weit außerhalb des Polygons) und einmal mit nach Deutschland verschobenen Daten. Das Ergebnis war in beiden Fällen genau das, was man erwarten sollte: einmal nichts, einmal alle Daten.
Sofern nicht irgendein Spezialfall zugeschlagen hat, wäre die Aussage im Wiki falsch. Hat jemand nähere Informationen?
nö,
nur dass es bei mir prima funktioniert:
- Daten in Josm geladen,
- test-polygon erzeugt, der Teilbereich definiert
- durch osmosis 4.1 gejagt <------------ 4.1 Ob es mit älteren Versionen geht ist mir
egalnicht bekannt.
Ergebnis: genau so wie ich es von Brett Henderson (dem Autor von Osmosis) erwartet habe: Null Problemo!
Gruss
walter
p.s. poly-files kann man übrigens ganz einfach im Josm erzeugen - plugin: Poly
Da bist Du mir doch gerade zuvorgekommen 
Grübel, Grübel, … Grübel?
2 Minuten später: Wiki !!!
Nun ja, man kann auch mit unsigned int32 arbeiten. Dann ergibt sich das 64 bit Problem erst wesentlich später bei 4-Giga IDs. (Gibt es dazu eine Voraussage?)
Es wäre nur dumm, wenn irgendwo doch eine signed int32 dazwischen wäre.
Nur so eine Idee.
Edbert (EvanE)
Es wäre nur dumm, ein Programm von signed int32 auf unsigned int32 umzustellen bloß um in einigen Jahren das nächste Problem zu haben, Wenn schon, denn schon - aber richtig.
Gruss
walter
Ein Programm, das mit unsigned int32 arbeitet, würde mit dem base-u32-Datensatz zurechtkommen, müßte aber am base-64-Datensatz scheitern (bzw. die IDs, die >= 2^32 sind, umklappen). Das passiert aber bei osmosis nach meiner Beobachtung nicht.
PS. Unterstellen wir mal, daß der Datenbestand weiter annhähernd linear um 1,5 M Knoten pro Tag wächst, haben wir etwas weniger als vier Jahre, bis weitere 2^31 Knoten verbraucht sind.
Jetzt gibt es eine
Die obige Zahl sollte bitte niemand zu ernst nehmen! Es handelt sich um eine grobe Extrapolation der Knoten-Erzeugung im Laufe des letzten Jahres. Niemand kann die weitere Entwicklung von OSM über einen solchen Zeitraum ernsthaft vorhersagen. Aber die Ausschöpfung des unsigned int32-Zahlenraums ist eher eine Sache von zwei bis drei Jahren als von zwei bis drei Monaten. Wer also in seinem privaten Tool nicht auf long int umsteigen will und keine negativen IDs braucht, kann das Problem noch eine ganze Weile hinausschieben.
Ok, dann ist nach deinen Beobachtungen die Aussage, dass OSmosis mit 64Bit IDs nicht klar kommt also falsch.
Das sehe ich ähnlich wie du. Knapp 4 Jahre bei linearem Wachstum bedeutet bei stärker als linearem Wachstum (was für die Zukunft zu vermuten ist) natürlich einen kürzere Zeit.
Da bin ich ganz deiner Meinung, wenn ein Programm umstellen, dann gleich zukunftsweisend also direkt auf 64Bit Integer.
Es mag aber Programme geben, die von vorneherein unsigned int verwendet haben, da keine negativen IDs auftreten dürfen (außer beim Upload, der hier aber nicht Thema war). So ein Programm wäre von der Überschreitung der 31Bit Marke noch nicht betroffen.
Edbert (EvanE)
Nicht nur nach seinen
Osmosis wurde mWn Mitte 2012 auf 64 Bit umgestellt. In welcher Version, ist mir nicht mehr bekannt. 0.41 und höher ist (bis auf unwahrscheinliche Flüchtigkeitsfehler) “sauber”. Eine andere Sache ist das aber mit den Plugins. Da die von verschiedenen (im Extremfall wörtlich zu nehmen!) Autoren geschrieben wurden, ist da alles möglich.
Gruss
walter
Ilya Zverev hat mittlerweile ein konkretes Stück Code benannt, wo ein Problem auftritt: die Funktion LongAsInt, letztlich ein geschützter Cast. Die Funktion wird von BitSetIdTracker und ListIdTracker benutzt. Ich kann mir nur vorstellen, daß diese beiden Implementierungen von IdTracker bei der Operation, die Walter und ich getestet haben, nicht zum Einsatz kommen, sondern ein DynamicIdTracker. Es sieht aber für mich so aus, daß überall der DynamicIdTracker als Standard verwendet wird.
Inzwischen scheint die Frage geklärt. Solange man nicht die Optionen --used-node oder --used-way verwendet, sollte es mit halbwegs aktuellen Versionen keine Probleme geben. Wenn man die Optionen braucht, muß man ihnen zusätzlich idTrackerType=Dynamic mitgeben; oder den aktuellen GitHub-Code verwenden, wo diese Einstellung mittlerweile Standard ist (in Version 0.42 dann natürlich auch, wenn sie herauskommt). (Das Scheitern von --used-node ohne bzw. die korrekte Funktion mit idTrackerType=Dynamic konnte ich mittlerweile nachvollziehen.)