[Imports] Burlington VT Building Footprints

[Paul Norman]

> From: Andrew Guertin [mailto:andrew.guertin at uvm.edu]
> 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))