Talk:OpenGeoDB
Svens approach is to move most of the data to OSM. Personally, I'd prefer to take only a subset for reference, while most of the roads should have a loc_id tag about the district where they belong to. (Martin 13.01.08 on talk Mailinglist)
Please no more OpenGeoDB uploads/updates
The data is simply to poor quality. In Westerwald, Germany area and around Gießen for example the village marker is often several hundreds of meters or even kilometers besides the actual village, the names have additions which do not belong there "Gießen, Lahn" etc. I cannot see the point to trash a reasonably clean dataset (OSM) with junk data. Good intentions, I suppose, but we should go there alone. Longbow4u 18:42, 28 January 2008 (UTC)
- As a general question: Do you complain about the low precision itself (which is poor, using a grid of 1/10 minute) or this location here - which does not necessarily represent the location of the village, but the location of the "Gemeinde". opengeodb could profit from OSM if those errors would be corrected within the opengeodb data itself. --traut 09:44, 29 January 2008 (UTC)
- I noticed that the points were aligned grid-like, but besides the actual locations. I did not know that OpenGeoDB has only a reduced resolution (1/10 minute). Why should such data be added to the OSM database? Now we do not know which places are at their correct locations and which are not. I complain generally about the incorrect data in OpenGeoDB. Nice to improve OpenGeoDB, but perhaps they should have imported OSM-Data afterwards and not the other way around. Longbow4u 12:25, 29 January 2008 (UTC)
- OpenGeoDB does not have a reduced resolution. But opengeodb got its first data from the nima sources: Potential_Datasources#GEOnet_Names_Server. As long as no one improves the quality of these numbers, they will remain on this grid. It's the job of the import script not to overwrite existing and better OSM data by primitive opengeodb data - this data should be only added to IMPROVE quality. I feel it was a flaw of the import script to add those duplicates. This is more a problem how to apply the import, less about the opengeodb data itself. --traut 12:49, 2 February 2008 (UTC)
I agree with Longbow4u - the mass import of OpenGeoDb data produces a mass of confusion. Where a place with matching name exists the additional data does not hurt, but now we have lots of place=village with the OpenGeoDb keys (and a slightly differing name!) at a location "aproximately at the center of a community (Gemeinde)" which duplicates the real village :-( --TrudeRO 23:02, 1 February 2008 (UTC)
- I did not want to sound too negative. Where I can, I have started correcting the data. Perhaps the added values are useful in the future. I then move the opengeodb markers to the supposedly right spots. Where there are double names, like "Westerburg, Westerwald", I delete Westerwald and delete the entry name in opengeodb_autoupdate, so it is not overwritten again to the former (wrong) status. I hope this is right. Longbow4u 14:22, 2 February 2008 (UTC)
- To my opinion the openGeoDB:... tags are simply attached to the wrong objects in OSM - probably a mapping of the hierarchical structure of openGeoDB to OSM objects is not possible 1:1! Almost any of those tags I found in my home region are describing a community (openGeoDB:type=Gemeinede) but are attached to the place=village which carries the same name ("capital" of the community) or when no match was found, a new place=village was created where no village is. In OSM the only thing describing a community may be the border lines to neighbor communities. I see the good intention behind this import - but the result is not satisfying :-( --TrudeRO 16:58, 8 February 2008 (UTC)
Please add type to relations
As per Relations, relations should come with a type tag specifying the kind of relation. Please add such a type tag to the relations. Also, please document the relation at Relations. Robx 10:31, 15 March 2008 (UTC)
New Dumps
New dumps are available from http://fa-technik.adfc.de/code/opengeodb/dump/
How to correct data?
I found a district ("Bezirk") whose area/polygon spans a way too large area in OS:
openGeoDB source data: http://fa-technik.adfc.de/code/opengeodb.pl?locid=60229;c=AT
This polygon is much too large for the region it should show ("Oberpullendorf") and therefore a lot of places in nominatim are incorrectly assigned to this region.
How can I correct this polygon shown in the map? I wasn't able to find it in potlatch or JOSM, any help how to do this would be appreciated.