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

Nick Bolten nbolten at gmail.com
Fri Nov 10 03:24:21 UTC 2017


Hi all! Just to be clear, I'm not recommending using any non-standard tags
for crossings at this time, though we're looking to eventually propose some
changes to the community and go through the proper process.

Given the way that the helper tool `crossify` works, it will be much more
straightforward for Vivek et al. to add a dedicated, no-holes polygon of
sidewalks first and then start adding suggested crossings lines. Their
direction is to wrap up the minority of remaining sidewalks ASAP so that
they can begin on a proper curated import of crossings. However, in the
meantime I'll be trying to find a strategy for starting on crossings ASAP.

On Wed, Nov 8, 2017 at 11:16 PM Vivek Bansal <3vivekb at gmail.com> wrote:

> Hi Michael,
>
> 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,
>
> Vivek Bansal
>
>
> On Tue, Nov 7, 2017 at 4:00 PM Michael Reichert <osm-ml at michreichert.de>
> wrote:
>
>> 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)
>>
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20171110/b5e4a176/attachment-0001.html>


More information about the Imports mailing list