[OSM-dev] Modeling OSM sidewalk data

Paul Norman penorman at mac.com
Wed Jul 13 06:49:55 UTC 2016


On 7/12/2016 3:44 AM, Andy Townsend wrote:
> On 12/07/2016 08:42, Paul Norman wrote:
>
> Rather than having sidewalk data available in a column, I instead with 
> a different highway value for "this road has a usable sidewalk".  We 
> already have a plethora of highway values, so the extra work to 
> support isn't high, and has the advantage that you don't need to mess 
> about with the schema (though you do need to reload the database) if 
> anything changes:
>
> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L258 
>

Don't you quickly start needing to have many many values for your 
highway column as you combine sidewalks, link status, cycleways, etc?

For me a sidewalk column is much easier to do than expand the highway 
class values and it avoids users downstream of me having to deal with 
sidewalks if they're not using them in their analysis or rendering.

> My initial goal was to be able to render sidewalks on unclassified and 
> tertiary roads.  Note that there are more values in that list than 
> you're probably expecting - that was what was found to be in the data 
> when I looked locally. 

I also see you're treating cycleways as sidewalks. I'm planning on 
handling them separately, which is another reason I'm using more columns.

> From the readme of https://github.com/ClearTables/ClearTables it 
> sounds like you're trying to process OSM data as it actually exists, 
> not "as it ought to be tagged", which means you might have to do 
> something "clever" to detect poorly mapped examples like the one 
> above, perhaps based on proximity.  I'd be interested to see what you 
> come up with...

I'm dealing with "tagging as it exists", which is slightly different 
than "data as it exists", so I don't have to worry about data errors 
like those disconnected ways. This is partially due to technical 
constraints, but even without them I'm not sure if I'd handle that case.

It's also going to a PostGIS database so there's no notion of if two 
linestrings are connected, only if they're touching.



More information about the dev mailing list