[Talk-ca] Address ranges

[Bob Jonkman]

On 23 Mar 2009 at 21:24 Richard Weait <richard at weait.com> wrote
about "Re: [Talk-ca] Address ranges[...]"

>> I'd rather see generated nodes (as per Richard Weait's suggestion) 
>> with additional "addr" tags, eg.
>> 
>> building=yes
>> addr:housenumber=123
>> addr:type=generated-blockface
>> addr:offsetlat=0.00003
>> addr:offsetlon=-0.00001
>> addr:offsetnodeid=<nodeid>
>> 
>> This would be an indication that it's a suitable candidate for 
>> replacement with observed data.  If the associated road node is moved, 
>> the building node doesn't necessarily have to be moved, but could be 
>> re-calculated (which opens its own can of worms).
>
>Are you combining two address data issues?  

Perhaps. The addr:offset* is intended to give a quantifiable value to 
the relationship between the road and the housenumber, and solves the 
problem of moving the road nodes after the building nodes/polygons 
have been created.  


>For block face addressing, we need to interpolate building location.
>That was when the arbitrary offset was suggested.  I believe we have _in
>other locations_ building point locations.  Are there addresses
>associated with those building points?  If so, no interpolation
>required.  

Agreed. If there's already a building then it should receive the 
housenumber, whether it's a single-node building or a polygon 
building. And, of course, this automated process should not be 
changing housenumbers where they already exist, or turning single-node 
buildings into polygon buildings!

>Also, Karlsruhe schema explicitly allows addr:housenumber as a node OR
>polygon.  So no need to fake the polygons to comply with the schema.  I
>believe that the sample image shows two point-buildings "6" and "4" on
>the north side of Bochumer Straße?   

>> One problem is that not all addresses are necessarily buildings.  
>> Sometimes a park, public square or empty lot has an address.  And all 
>> buildings aren't necessarily houses, so I'm not sure that 
>> "housenumber" is the most appropriate tag name.
>
>But it is what we have for the schema.  The discussion suggests that we
>can make suggestions.
>http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/House_numbers/Karlsruhe_Schema

Yes, I'm merely making suggestions.  However, the Talk page is only 
convincing me that the Karlsruhe schema is not ideal for interpolated 
housenumbers where the data is imported.  While it's a nice compact 
method, and good for people submitting data, I'd much rather see 
polygon buildings generated from imported data than generating a 
related way with nodes for interpolated housenumbers. 

The Karlsruhe schema puts a way on the map that doesn't correspond to 
a physical feature. All in all, I prefer separate building polygons in 
a relation with the street.

>> When I worked at the City of Toronto and had access to their Central 
>> Property Register database there were different concepts of municipal 
>> addresses, postal delivery addresses, and courtesy addresses.  I 
>> expect that GeoBase captures the municipal addresses. 
>
>Which is the one that is easiest to detect when walking past the
>building?  Municipal?  

The courtesy address, which is how people commonly refer to the 
property. For example, a building on the corner of two streets may 
have its municipal address on the smaller street, but a courtesy 
address on the main street.  When a property is severed and each new 
parcel receives a new municipal address, the former address may be 
assigned as a courtesy address to one of the new parcels. The 
municipal addresses also capture property lot numbers, parcels, &c. 
Usually the municipal, postal and courtesy address are all the same. 
Things become interesting when they're different.  (It's been over 10 
years since I worked with the Toronto Central Property Register, so 
things may have changed, especially after amalgamation)


>> Also, I'm in favour of generating a small polygon (square) rather than 
>> a single node.  This fixes Michel Gilbert's rendering problem, and 
>> also more closely reflects reality.
>
>I respectfully disagree.  And I hope that adding addr:housenumber will
>work as per my guess above.  
>
>Some have said that we shouldn't tag for the renderer.  And then others
>have said that and still done amazing work by tagging for the renderer.
>http://weait.com/content/science-fair-cern

Using a polygon instead of a node for a generated building isn't 
tagging for the renderer, but more closely tagging for reality. So 
what needs to be fixed?  Is single-node data inadequate to represent 
buildings with the renderers, or are the renderers inadequate to 
represent buildings with single-node data? 

>Adding a fake polygon may also subtly discourage mappers from going and
>mapping the buildings.  "Look at those cute, even, rectangular
>buildings.  Obviously I don't need to fix that with aerial images..."  

I'm more likely to believe that someone will see the incorrect 
building outline, and rush in to fix it.  Single-node buildings don't 
render (yet), so they're likely to escape attention.

>Kind of like hacking css for a month to make it work with IE5.  Wasted
>effort; bad for the psyche.  Design for the standard and you are certain
>to work with the browsers of the future (renderers of the future).  

Been there, done that (for CSS on IE, anyway). So, knowing that 
single-node buildings aren't recognized by the renderers, what's the 
correct standard?  http://wiki.openstreetmap.org/wiki/Building says 
the "building" tag is for areas, and doesn't mention single nodes. Not 
knowing if future renderers will render single-node buildings (and 
knowing that current renderers don't) I still think polygon buildings 
are preferred.


>My thoughts, while my tiles render.  ;-)
>
>Best regards,
>Richard


May your tiles render speedily!

--Bob.