[Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA
dislt258 at newschool.edu
Sun Aug 7 00:58:23 UTC 2016
Thank you for your comments Greg! We've been drafting a longer response
that we wanted to share, and this seems like a good moment to jump in and
do so. Firstly, thank you to everyone for your engaging feedback! We’ve
learned a huge amount about the weaknesses and strengths of our proposal.
We think it would be helpful to talk about our motivations in posting this
import (and the schema suggestion), to give our points some context. We
have started this project with the goal of making sidewalks in OSM more
useful for the greater community, particularly people with limited
mobility. With its principles of openness and inclusion, OSM is uniquely
positioned to adopt a data model that can make a big difference for people
who use wheelchairs, crutches, or otherwise have difficulties walking,
while also improving the data in the map. While we hope this will have a
global impact, we are starting with a local import, are engaging the local
OSM community, and are setting up stakeholder relationships for the
maintenance of the data.
We would like to distinguish, as best we can, our schema proposal (on the
OSM wiki) from the import. The data to be imported does not have enough
metadata to make use of all the tags we are suggesting, and primarily comes
down to annotating the basic feature-level descriptions of sidewalks,
crossings, and curb ramps. We may be able to add one or two more pieces of
information (like width, surface, and kerb tags), but we consider this to
be an opportunity more than a requirement. In all cases, the tags we would
use are not new or in violation of OSM standards, in our understanding -
they are all in heavy use in many locations, with wiki entries, even though
tagging streets with sidewalk information is popular in other locales.
To address some of the concerns about community engagement and our import
proposal in general, we’d like to detail what we have done so far to make
it clear that we’re engaging with the local community and attempting to go
through all the right steps.
We started (after much research) by posting the schema towards the end
of June to get feedback
We presented our schema at the SOTMUS to get direct feedback, especially
to learn how it could adapt to places outside of Seattle. We also presented
our plan to actually to do an import of Seattle data to test this
schema, and have received positive feedback from the local OSM community so
far. This put us in contact with a large number of OSM community members
from the U.S. and international communities, and we received overwhelmingly
We also connected with the LA building import team (at the SOTMUS) and
have modeled our import proposal after theirs.
After posting the proposal, we’re engaging the tagging and import
mailing lists to get more feedback in case there are unforeseen problems.
Next we plan on running a test import from start to finish, converting
Seattle municipal data to (a subset of) the proposed schema, with an output
of OSM XML. We’ll then test integrating with a locally hosted copy of
OpenStreetMap through a human verification process (the tasking manager +
JOSM plugins), to meet with OSM best practices.
Only once we’ve learned from this process, and ensured that our schema
meets community expectations were we planning to actually import the
Seattle data set. The goal here would be to take a first step to be able to
show the benefits of having this standardized sidewalks schema, especially
for the limited mobility community.
For maintainability (and immediate impact), we have several stakeholder
relationships interested in this project. These include the NGO Feet
First, the Puget Sound Regional Council (they are discussing an official
capacity), the King County Mobility Coalition, groups within King County
Metro, and of course the local OSM community, with whom we’re hosting a
Mapathon on August 7, 2016.
What are everyone’s thoughts? Are there any additional steps you would
Regarding the import challenges:
In terms of putting the burden on existing volunteers, we actually think
that this could be used as a strategy to get more people into mapping. We
were lucky enough to speak to a lot of OSM meetup organizers at SOTMUS and
something which came back consistently is: they need interesting projects
to get people to turn out for mapathon events, and projects with a social
angle are really effective at this. Obviously this isn’t a new idea, and we
can point to the work done by the HOT team as a really positive example of
this. Additionally, we have found that a more human-centric approach draws
people in. We are interested, afterall, in improving walking conditions for
We are also developing mapping tools (iD modes, mobile applications, and
potentially a JOSM plugin) to make mapping sidewalks, crossings, and curb
ramps easier. We are testing a few of these tools at the OSM mapathon that
we are co-hosting at the University of Washington this weekend. We’ll be
sure to report back on how this went, and if you’re local come stop by!
In short, we want to get more people mapping, and we’re working on making
it easier to map pedestrian features.
Keep the comments coming, we really appreciate everyone who has contributed
to this thread :)
Tom, Meg, Jess, Nick, Anat and Kaicheng.
On Sat, Aug 6, 2016 at 3:40 PM, Greg Morgan <dr.kludge.gm at gmail.com> wrote:
> On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm <frederik at remote.org> wrote:
> > Meg,
> > sidewalk tagging in OSM is a complex issue. The fact that sidewalks
> > are not tagged as individual geometries is not purely a shortcoming, it
> > is a compromise that keeps OSM data editable. Having individual
> > geometries for every single sidewalk on the planet will not only
> > massively increase the data volume but also require new and better tools
> > for editing, e.g. moving the geometry of a street without having to move
> > three parallel lines manually and so on.
> > There have been several local imports of sidewalk data that were removed
> > again because lack of prior discussion and/or because they were
> > single-purpose imports that did not care about integration with the rest
> I don't see how that is relevant here since Meg is engaging in a
> > of OSM (for example: what should rendering engines do with sidewalks;
> Again relevance: I am still waiting for a stop sign to be rendered a
> year after it was requested. If we wait until a stop sign gets all
> artsie and fartsie, then it will never be rendered and it will never
> be mapped or shall I say mappers will become uninterested without a
> reward for their efforts. We deny one stop light towns the pleasure
> of seeing something happen on the map. We need this kind of data
> before the renders can even have some use cases to work from.
> > how do they integrate with normal footways; how is a sidewalk linked to
> > the road along which it runs so that routing engines can say "follow
> > sidewalk along XY road" instead of "follow unnamed footway"; how can
> > routing and rendering use individual sidewalks and still gracefully fall
> > back to another method where these are not defined, and so on).
> > People are experimenting with different ways of mapping sidewalks.
> > Under no circumstances should you perform an import that creates facts
> > before your proposal for separate mapping of sidewalks has been
> > discussed more widely.
> I look at the recent turn lane work that MapBox is performing. They
> have done a wonderful job of finding issues and developing use cases
> for the rest of the community. Far worse than the alleged GIGO of
> this import is the NINO. Without out MapBox's activity we would not
> have a well developed definition of turn lanes. Without sideway data
> mapped and worked on, we'll get no where with these kinds-of
> discussions. I look forward to see what the Washington community will
> find. I am still working out details of my sidewalk edits. I'd like
> to build on the Washington data that will be developed.
> Thank you Meg.
> Imports mailing list
> Imports at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us