[Imports] Uploading sidewalks in San Jose, California, US

Michael Reichert osm-ml at michreichert.de
Tue Nov 7 23:59:07 UTC 2017


Hi,

Am 20.10.2017 um 00:43 schrieb Michael Reichert:
> this is a follow-up of the discussion of changeset 52318833
> (https://www.openstreetmap.org/changeset/52318833).
> 
> The sidewalk data has been lying around in OSM for about a month. It was
> errorenouos and made pedestrian routing unusable. An import should not
> reduce the data quality.
> 
> There were only few comments on the mailing list during the discussion
> of this import but this does not mean that the imported data is immune.
> The import guidelines are rules which *reduces* the probability that the
> import will be reverted if you follow them. If there are serious issues,
> a revert (as one method of cleanup) is possible.
> 
> I asked to fix the issue on this mailing list and added changeset
> comments to some changesets of some users who participated the import to
> make them aware. I did not see a real progress on the issue and decided
> to mention a deadline. If a manual cleanup (manual addition of
> connections) starts, there is a progress and I achieved what I want:
> Imported data should not be in OSM in a half-baked state.
> 
> A revert does not mean that the data can never be imported again. If
> there is an improved plan which includes addition of
> crossings and a proper connection to the road network at the time the
> data is uploaded (or within a few hours afterwards), I will agree with
> the import. I offer to produce a OSM XML file which can be loaded into
> JOSM. The objects will have their old IDs and history will be preserved.
> If you avoid editing in the same area and regularly upload and download
> during your activity, it is even possible that multiple users in
> parallel re-import (and add connections) the data.

This posting is now more than two weeks ago. The people behind the
import wrote that they will fix their issues. I had a look on the
current state of sidewalks in San Jose and I am disappointed.

https://overpass-turbo.eu/s/sPs

The query highlights all highway=footway which have been created or
modified since my last email. If missing links between sidewalks and
streets were added in a neighbourhood, the map should be blue in that
neighbourhood. Indeed, the map is blue at some spots but this blue color
is not caused by fixing but by an ongoing import:

Let's have a look at the cluster in the south west near Stratford Middle
School. There are sidewalks which were imported two days ago. The
connectivity of these sidwalks is only a little bit better than in the
first part of the import. They are connected to intersecting service
roads (e.g. parking aisles) but they are not connected to the streets at
street intersections. They are part of the routing graph but they are
only connected to the rest of the world at one or two locations and
therefore routing peninsulas.

Please have a look at Seattle and Graz. That's how sidewalks should be
connected:
https://www.openstreetmap.org/#map=19/47.06770/15.43888 (Graz)
https://www.openstreetmap.org/#map=19/47.66302/-122.30771 (Seattle)

A lack of connections results in routing errors:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.25844%2C-121.90588%3B37.25385%2C-121.90695#map=17/37.25552/-121.90616

I wonder why it takes so long to add the missing connections.
It is not that difficult to add proper intersections. I just did a test
on the area between US 101, Tully Road, McLaughlin Avenue and G21.
https://www.openstreetmap.org/changeset/53596607
I needed 12 minutes to add 82 ways (each two tags: highway=footway +
footway=crossing) and 136 intersection nodes (highway=crossing +
crossing=uncontrolled). The numbers on the changeset are little bit
different because I spotted some errors before uploading them. An
additional check afterwards is a good idea. If you trace fast, you make
lots of errors (own experience).

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20171108/f48c9632/attachment.sig>


More information about the Imports mailing list