Hallo,
die Wochennotiz Nr. 120 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/2012/11/wochennotiz-nr-120/
Viel Spaß beim Lesen!
Am Dienstag könnte es soweit sein. Wer erstellt den Node mit der ID 2000000000
Cool, dann ist es also nicht mehr weit bis zum Integer Überlauf… 
Sind die IDs nicht irgendwann auf 64 Bit umgestellt worden? Und sollten die nicht eigentlich unsigned sein? (Wobei, JOSM zumindest verwaltet die neu zu erstellenden Objekte mit negativen IDs, also vielleicht doch nicht?)
Ja in der DB, aber es könnte noch das eine oder andere Tool geben, welches mit 32-bit Integern arbeitet, die fallen dann
auf die Nase.
Der Standardimporteur mag auch Vorzeichen: osm2pgsql speichert Objekte, die es aus Relationen bildet mit negativen IDs, um nicht mit den anderen Objekten in Konflikt zu geraten. Aus den vielen Linien der Grenzrelation Nr 934744 wird dann ein Polygon Nr -934744.
Bin auch gespannt, was uns alles um die Ohren fliegt. An die Datenbank wird gedacht, aber wer weiss schon was noch alles mitspielt zwischen Editor und gerenderter Karte oder Router…
Grüße, Max
Naja gut, dann gibts ebend mal ne Downtime 
Von jedem unserer “vielen” Entwickler zu verlangen ausführliche Unitttests zu erstellen, würde ich als massiven Hemmschuh empfinden…
gut geschätzt: ist am Dienstag in Portugal aufgeschlagen http://www.openstreetmap.org/?node=2000000000
Es wird allerdings erst bei id 2 147 483 648 (2^31) kritisch.
Gruss
walter
Auf jeden Fall osm2pgsql für Windows. Die Version ist uralt (April 2010) und bisher hat es keiner geschafft eine aktuelle Version zu kompilieren.
Christian
Auf der dev-ML wurde mal osm4windows.org/downloads/ als “alpha” erwähnt.
Ich hatte das osm2pgsql neulich kurz angetestet (inkl. PBF-Unterstützung) und bei mir auf WinXP keine Probleme festgestellt. Allerdings ist die Version “0.80.0 32bit id space”, d.h. das ID Problem ist mit diesem konkreten Build noch nicht behoben.
Gruß,
Norbert
Ich meinte gar nicht so sehr die viel genutzten Tools. Ich dachte eher so an das Kleinzeug, das jeder nur für sich getippt hat: Irgendwelche php oder C oder perl-Progrämmchen. Da muss natürlich jeder selber sehn, was auf seinem System 2147483647+1 ist, aber es wird Zeit…
Grüße, Max
perl -e 'printf("%d\n",50000*50000);'
-1794967296
Vorhersagen auf Sicht von zwei Tagen sind ja langweilig, die schafft manchmal sogar der Deutsche Wetterdienst.
2^31 dürfte ungefähr am 03. Februar erreicht werden, Weihnachtseffekte noch nicht berücksichtigt (also vermutlich eher ein paar Tage früher)
Zumindest bei Emacs tritt kein (neues) Problem auf: Da haben die OSM-Knoten den integer-Zahlenbereich (der 32bit-Version) bereits im Oktober 2009 gesprengt.
Na, hat schon jemand feuchte Hände wegen 2<<30? Ungefähr am 07. Februar dürfte es soweit sein, das ist noch gut eine Woche.
Oh weh.
Ist das eine 32Bit-perl/OS?
$ perl -e 'printf("%d\n",50000*50000);'
2500000000
$ perl -e 'printf("%d\n",500000000*500000000);'
250000000000000000
$ perl -e 'printf("%d\n",5000000000*5000000000);'
-1
$
Nö, eine 32-Bit-Version von perl auf einer 64-Bit-Version des Betriebssystems. Keine Ahnung wie ich dazu komme 
“perl -e ’ print 500000500000;'" funktioniert dort übrigens und "perl -e ’ printf(“%s\n”,500000500000);'” geht auch. Nur die Formatoption für ganze Zahlen im printf haut nicht hin, weder mit %d noch mit %ld…
Ich glaube, ich verwende das nirgends beim Umgang mit OSM-Ids, aber genau solche kleinen Gemeinheiten machen es einem schwer, vorher zu sagen, ob was schief laufen wird.
Grüße, Max
Nahmd,
Also wirklich!
perl -e 'printf("%.0f\n",5000000000*500000000);'
2500000000000000000
14 Jahre alter Rechner, der zum letzten mal vor 3 Jahren ein OS-Update gesehen hat.
Gruß Wolf
Nein, auf Gleitkommazahlen auszuweichen ist keine Option, da bekommen zu viele Objekte die gleiche ID
perl -e 'printf("%.0f\n",5000000000*500000000+1);'
2500000000000000000
Nahmd,
Tsk, tsk. Wieso alles übertreiben:
perl -e 'print 1<<31,"\n",30000000*30000000+1,"\n"'
2147483648
900000000000001
Für die nächsten paar Jahre reicht die Mantisse von Double noch aus. 
.oO( und außerdem könnte man aus Id-Sharing einen neuen ökologischen Trend machen )
Gruß Wolf
Ich frage mich bloß, warum Du die IDs von Objekten miteinander multiplizieren willst. Für “normale” Anwendungen reichen die 15+ Stellen in IEEE754-double vorerst völlig aus.
Nahmd,
Guck weit nach oben im Thread: Multiplizieren als schnelle Methode, einen Overflow/Wrap zu erzeugen.
Ich nutze aber ohnehin keine Doubles. Gleichheitsabfrage (==) bei Fließkomma ist ein Grund für eine fristlose Kündigung
Gruß Wolf
Klar, aber dann hat
den Zusammenhang zu Objekt-IDs hergestellt.