<div dir="ltr">The fact that small disconnected pedestrian islands breaks routing is a problem for routers more than the map, although high-quality pedestrian transportation network data is the ideal. It will never be the case that the entire pedestrian network is added all at once, or without disconnected portions. On the router end, it should be as simple as either removing disconnected subgraphs or preventing disconnected subgraphs from being selected during the initial 'find the closest valid way' step.<div><br></div><div>I'm in contact with the mappers putting in the time to map pedestrian ways in San Jose and they're putting together a dataset of street crossings to start importing. I'd like to suggest that we support their endeavor and time commitments by supporting the inclusion of street crossings, rather than discouraging mapping via threats of reverts on changesets. Everyone's at the table and working to improve the data.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 19, 2017 at 3:44 PM Michael Reichert <<a href="mailto:osm-ml@michreichert.de">osm-ml@michreichert.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Minh,<br>
<br>
this is a follow-up of the discussion of changeset 52318833<br>
(<a href="https://www.openstreetmap.org/changeset/52318833" rel="noreferrer" target="_blank">https://www.openstreetmap.org/changeset/52318833</a>).<br>
<br>
The sidewalk data has been lying around in OSM for about a month. It was<br>
errorenouos and made pedestrian routing unusable. An import should not<br>
reduce the data quality.<br>
<br>
There were only few comments on the mailing list during the discussion<br>
of this import but this does not mean that the imported data is immune.<br>
The import guidelines are rules which *reduces* the probability that the<br>
import will be reverted if you follow them. If there are serious issues,<br>
a revert (as one method of cleanup) is possible.<br>
<br>
I asked to fix the issue on this mailing list and added changeset<br>
comments to some changesets of some users who participated the import to<br>
make them aware. I did not see a real progress on the issue and decided<br>
to mention a deadline. If a manual cleanup (manual addition of<br>
connections) starts, there is a progress and I achieved what I want:<br>
Imported data should not be in OSM in a half-baked state.<br>
<br>
A revert does not mean that the data can never be imported again. If<br>
there is an improved plan which includes addition of<br>
crossings and a proper connection to the road network at the time the<br>
data is uploaded (or within a few hours afterwards), I will agree with<br>
the import. I offer to produce a OSM XML file which can be loaded into<br>
JOSM. The objects will have their old IDs and history will be preserved.<br>
If you avoid editing in the same area and regularly upload and download<br>
during your activity, it is even possible that multiple users in<br>
parallel re-import (and add connections) the data.<br>
<br>
Am 16.10.2017 um 08:16 schrieb Minh Nguyen:<br>
> That is indeed a problem we hope to eradicate once the crosswalk mapping<br>
> project gets underway. It isn't unique to imports, though: for example,<br>
> the adjacent town of Los Gatos has been mapped fairly extensively with<br>
> sidewalks, and many crossings are missing there too:<br>
><br>
> <a href="http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22855%2C-121.97027%3B37.22866%2C-121.97025" rel="noreferrer" target="_blank">http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22855%2C-121.97027%3B37.22866%2C-121.97025</a><br>
><br>
><br>
> <a href="http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22914%2C-121.96464%3B37.22918%2C-121.96475" rel="noreferrer" target="_blank">http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22914%2C-121.96464%3B37.22918%2C-121.96475</a><br>
><br>
><br>
> Even where crossings were added, they weren't connected to the road<br>
> network, leading to very roundabout routing:<br>
><br>
> <a href="http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22733%2C-121.96631%3B37.22697%2C-121.96609" rel="noreferrer" target="_blank">http://www.openstreetmap.org/directions?engine=graphhopper_foot&route=37.22733%2C-121.96631%3B37.22697%2C-121.96609</a><br>
><br>
><br>
> These problems come up often from mappers who are unfamiliar with<br>
> pedestrian router needs. I mention these examples not to pass the blame<br>
> but rather to point out that the problem is not new in this area, yet<br>
> we're working deliberately to ensure that mappers won't have to worry as<br>
> much about these issues in the future.<br>
><br>
> [1] <a href="http://overpass-turbo.eu/s/smw" rel="noreferrer" target="_blank">http://overpass-turbo.eu/s/smw</a> versus <a href="http://overpass-turbo.eu/s/smv" rel="noreferrer" target="_blank">http://overpass-turbo.eu/s/smv</a><br>
<br>
A problem in an adjacent town cannot be used as a justification for<br>
deficiencies of an import. We are much more liberal with people mapping<br>
sidewalks manually than imports. An import adds more data in a shorter<br>
time and a problem in the process can therefore break more. That's why<br>
the import discussion is necessary but in this case people who offer<br>
their spare time to give regularly advice were busy with other things<br>
and forgot your import.<br>
<br>
Best regards<br>
<br>
Michael<br>
<br>
<br>
--<br>
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten<br>
ausgenommen)<br>
I prefer GPG encryption of emails. (does not apply on mailing lists)<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
</blockquote></div>