[Imports] Uploading sidewalks in San Jose, California, US
3vivekb at gmail.com
Thu Nov 9 07:14:57 UTC 2017
First off thanks for noticing our work with the ongoing import and also
contributing to intersections! We are one step closer to our goal of a
working pedestrian network for our area! I estimate you’ve completed about
2 of the 575 total task squares with your efforts. Thus (6 min)/task *575
(tasks) /60 (minutes/hour) = 57 hours of work ahead of us :)
We are having a mapathon this Sundayin the spirit of #osmgeoweek. You and
all are welcome to participate in sunny San Jose or help import/validate
from afar (9:30am-3:30pm PST). We hope to finish importing the sidewalks
then. So far we have about 65% imported (375 of 575) with 18% validated.
After which we will finish documenting our tagging scheme and focus on
intersections with the tasking manager in a systematic efficient fashion
(right now it’d be a total mess to just stop the import! How would we know
the areas to fix? And then start an import again? and stop each time to do
intersections? So confused.).
While sidewalks as separate ways seem to be relatively established, it
seems how to best tag crossing is an ongoing discussion. We want to figure
out the way to balance speed at accomplishing our tasks as well as making
it most useful for the future. We are thinking highway=footway +
footway=crossing, and then crossing=marked or crossing=unmarked. Nick and
others feel like uncontrolled is not very specific (what does uncontrolled
even mean? if it’s marked but uncontrolled? Unmarked probably always
means uncontrolled, and then marked without any other tags would also mean
uncontrolled? ). And then making sure to have crossing on the intersecting
node with the road, and if possible a node at where the sidewalk meets the
road for future kerb tags. After this base is down and the network is
functional, the traffic_signals and other tags can be added properly.
All the best,
On Tue, Nov 7, 2017 at 4:00 PM Michael Reichert <osm-ml at michreichert.de>
> 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.
> 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
> 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:
> 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.
> 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
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> I prefer GPG encryption of emails. (does not apply on mailing lists)
> Imports mailing list
> Imports at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports