Fixed a serious bug with insertion of data

Sakari A. Maaranen — Tue, 09 Mar 2010 06:38:13 -0000

Although updating data and detecting changes in data worked in revision 71, insertion of new data unfortunately did not. This was caused by a misplaced time zone handling statement that only affected inserts.

Of course I was so busy testing updates that the bug with inserts slipped through. My apologies for not correcting this sooner.

The bug (ID: 2965468) was fixed in revision 72 and insertion of new data is working again.

Many thanks to Bruce for pointing this out!

Testing change detection

Sakari A. Maaranen — Sun, 07 Mar 2010 09:59:19 -0000

Detecting if OSM data has changed has a few tricks and quirks.

- Firstly, the data is not always complete (with missing fields), so we can't always compare all the fields.
- Secondly, there are plenty high precision floating point values and even the smallest rounding error can cause false positives.
- Thirdly, processing all the timestamps needs to be done in UTC.
- And of course we don't want to replace more recent data with its older version (when we know the OSM data primitive version.)

All these and more details had to be taken into consideration and tested. There were related bug fixes up till revision 70, which seems to detect changes correctly now.

If you built a database with a previous version of OSM2PostGIS, a lot of changes will be detected because of these bug fixes. Now that the rounding errors and time zone handling are fixed, the database should remain much more stable in future.

Skipping unchanged data seems to work now.

Sakari A. Maaranen — Sat, 06 Mar 2010 19:53:18 -0000

The revision 68 should now be able to detect if any of the OSM primitives have actually changed and skip writing when there's no need. This check did not work at all with OSM changesets before. Now it should.

If you have built a database using a previous version of OSM2PostGIS, and you don't want to rebuild from scratch, you must add the status column to these four tables: osm_changesets, osm_nodes, osm_ways, and osm_relations.

To do this:
ALTER TABLE * ADD COLUMN status smallint DEFAULT(0) NOT NULL;

Of course, you need to replace the asterisk with each of the aforementioned table names in turn. Alternatively you can rebuild the whole database.

As always, this is the best version of OSM2PostGIS so far.

Configurable target relational model

Sakari A. Maaranen — Sun, 28 Feb 2010 03:27:47 -0000

Fully configurable target layers support has been added to OSM2PostGIS revision 53. The user can now configure the relation names (database tables) and attribute names (database columns) in the feature specification file. The attributes can be configured independently for each table or layer.

A total makeover for the project web unveiled

Sakari A. Maaranen — Thu, 18 Feb 2010 23:32:26 -0000

Check out the new look for OSM2PostGIS Project Web at http://osm2postgis.sourceforge.net/

Area and line geometry separated

Sakari A. Maaranen — Sun, 31 Jan 2010 23:12:09 -0000