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

Michael Reichert osm-ml at michreichert.de
Thu Oct 19 22:43:47 UTC 2017

Hi Minh,

this is a follow-up of the discussion of 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.

Am 16.10.2017 um 08:16 schrieb Minh Nguyen:
> That is indeed a problem we hope to eradicate once the crosswalk mapping
> project gets underway. It isn't unique to imports, though: for example,
> the adjacent town of Los Gatos has been mapped fairly extensively with
> sidewalks, and many crossings are missing there too:
> http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22855%2C-121.97027%3B37.22866%2C-121.97025
> http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22914%2C-121.96464%3B37.22918%2C-121.96475
> Even where crossings were added, they weren't connected to the road
> network, leading to very roundabout routing:
> http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22733%2C-121.96631%3B37.22697%2C-121.96609
> These problems come up often from mappers who are unfamiliar with
> pedestrian router needs. I mention these examples not to pass the blame
> but rather to point out that the problem is not new in this area, yet
> we're working deliberately to ensure that mappers won't have to worry as
> much about these issues in the future.
> [1] http://overpass-turbo.eu/s/smw versus http://overpass-turbo.eu/s/smv

A problem in an adjacent town cannot be used as a justification for
deficiencies of an import. We are much more liberal with people mapping
sidewalks manually than imports. An import adds more data in a shorter
time and a problem in the process can therefore break more. That's why
the import discussion is necessary but in this case people who offer
their spare time to give regularly advice were busy with other things
and forgot your import.

Best regards


Per E-Mail kommuniziere ich bevorzugt GPG-verschl├╝sselt. (Mailinglisten
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/20171020/896bdcb3/attachment.sig>

More information about the Imports mailing list