Nahmd,
Ich benutze 40-bit-Integer. Und suche noch ein Verfahren, die gleichzeitig word-aligned und lückenlos im Speicher abzulegen 
Gruß Wolf
Ich wollte nur Wolfs “%f”-Lösung nicht unkommentiert stehen lassen, könnte ja sein, dass jemand das aufschnappt und übernimmt.
Die Idee “Wenn integer nicht ausreicht, nehme ich halt float, dann kann ich bis 10^308 zählen” klingt so verführerisch, dass jeder schon mal drauf reingefallen ist und erst später merkt, dass bei grossen Zahlen x+1=x gilt.
Nahmd,
Perl rechnet immer in double (zumindest wechselt es wenn nötig automatisch zu double). Deshalb kann ich leicht mit 15-stelligen Ganzzahlen rechnen ohne Gefahr, dass n+1==n. Und 15 Stellen reichen (fürs erste) für uns. So gesehen hat Perl ziemlich lange Integer. Und unformatiert (oder mit %s-Format) kann man diese riesigen Zahlen auch problemlos ausgeben.
Nur Bitoperationen (&,|,^,~,<<,>>) werden auf int32 gerechnet – und halt das %d-Format.
Dass %d so implementiert ist, dass zuerst nach int32 konvertiert ist, wusste ich allerdings noch nicht. Wie so oft: bei OSM, da wird was gelernt.
Gruß Wolf
Es sieht nicht so aus, ob wir heute noch die id 2’147’483’648 (2^31) erreichen. Es fehlen noch ca 2’200’000 - das wird also morgen der Fall sein.
Das stimmt. In den letzten Tagen und Wochen war der tägliche Zuwachs etwas geringer als zuvor; auch meine Schätzung aus #11 lag um (voraussichtlich) fünf Tage daneben.
Ein Tag mehr, um in letzter Minute lebenswichtige Software zu reparieren
Gut dass morgen nicht Freitag der 13te ist. 
Noch 1,5 Millionen, ungefähr ein Tagewerk (Do, 22:30 MEZ).
1 Million. (Fr, 15:00 MEZ)
900.000 (Fr, 16:00 MEZ)
Eventuell ist es doch erst Samstag soweit. Noch 500.000. (21:00 MEZ)
01:00 MEZ bzw. 00:00 GMT: noch 300.000. Aber heute ganz sicher 
Aktueller Stand:
wird wurde jede Minute aktualisiert - einfach shift-reload machen.
Gruss
walter
da ist er: http://www.openstreetmap.org/browse/node/2147483648
Ganz “normaler” Node in einem einfachen Track mitten in der Pampa - mal sehen, ob den einer kapert.
Nahmd,
Noch ~300.000…
Gerhard Polt meint dazu: “gell des ziagt sich”.
Gruß Wolf
2^31
Dachte nicht, daß es so lange dauern würde. Hätte bloß noch gefehlt, daß ein Spaßvogel wenige Nodes vorher die Datenbank auf R/O schaltet.
R/O nicht, aber gerendert werden die neuen Nodes derzeit vorsichtshalber auch nicht…
http://wiki.openstreetmap.org/wiki/Platform_Status
Grüße, Max (der sich an Silvester 99 erinnert )
Und Nominatim ist offenbar auch nicht “N 1<<31 compliant”.
Kalter Kaffee, das ist doch schon fast -87 Jahre her.
Vorsichtshalber - oder doch ein “plötzlich unerwartet aufgetretenes Problem” wie der Schneefall gerade im Winter bei der Bahn?
Gruss
walter
Falls ich jemanden beruhigen kann: Die Verarbeitung auf Debian 6.0.6 64-Bit, Postgres 8.4.13 mit osm2pgsql-Schema und hourly-diffs eines kleinen Gebietes funktioniert bei mir mit osm2pgsql 0.81.0 (64bit id space) und Osmosis 0.41. Java ist Version 1.6.0_26.
Ich hab anlässlich des 32. Bits nichts geändert, ausser in den letzten Wochen mal die neueren Versionen der Programme geholt.
Der UMN-Mapserver zeichnet daraus ein heute morgen entstandenes Neubaugebiet. Auf “richtige” Nodes mit eigenen Tags muss ich noch bis morgen warten.
Nachtrag 16:20 Uhr: Inzwischen rendert Mapnik das Gebiet auch.
Die frischen Geofabrik-Extrakte fallen ein wenig klein aus:
<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="pbf2osm">
</osm>
Ob das auch an 2^31+x liegt?
Nachricht an woodpeck ging raus.
Maptool für Navit konnte anscheinend auch nicht mit node-ids über 2^31 umgehen. Da gab’s aber gestern ein Update dazu. Seit rev-5376 funktioniert nun auch maptool…