> From: Andrew Guertin [mailto:[email protected]] > Subject: Re: [Imports] Burlington VT Building Footprints > > On 01/15/2013 09:38 AM, William Morris wrote: > > 1. trim trailing (and leading) spaces from values > > > > Weirdly, these are being added when I pipe the shapefile through > > ogr2osm (both Paul's and Andrew's versions). I'm not sure what's going > on there. > > Probably the spaces are present in the source data; try adding a strip() > in the translation.
It's a combination of the source data, the source data format and the ogr driver. I've mainly seen it with arcgis shops exporting shapefiles. I suppose I could .strip() the fields. Most of my translations do this and it would make some sense to do it in ogr2osm. This would break any existing translations which do checks of the form attrs['field'] == ' 1 ', but those tended to break anyways. The 9.00000 problem is slightly more complicated. I believe what is going on is the fields are specified as numbers, not as strings and then a conversion somewhere ends up adding 0s. More investigation is required to determine the exact cause, but this is likely a mistake on the part of the source of the shapefile. Saying that housenumbers are numbers is to say that houses numbered 9 and 9.0 are the same, they should be stored as strings instead. Fortunately if this problem does occur it should occur on *every* object, making it very easy to spot so it should be caught when the person is writing their translation. For a field where it's really a number (e.g. heights) I used this python to sanitize the heights (from https://github.com/pnorman/ogr2osm-translations/blob/SurreyCombined/SurreyCo mbined.py#L185) tags['height'] = str(round(float(attrs['POLE_HT'].strip()),3)) _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
