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. 1. We started (after much research) by posting the schema towards the end of June to get feedback 2. 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 positive feedback. 3. We also connected with the LA building import team (at the SOTMUS) and have modeled our import proposal after theirs. 4. After posting the proposal, we’re engaging the tagging and import mailing lists to get more feedback in case there are unforeseen problems. 5. 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. 6. 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. 7. 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 recommend? 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 everyone. 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...@gmail.com> wrote: > On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm <frede...@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 > conversation. > > > 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. > https://github.com/gravitystorm/openstreetmap-carto/issues/1683 > > > > 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. > https://github.com/mapbox/mapping/wiki/Mapping-guide- > for-turn-lanes-from-imagery > https://github.com/mapbox/mapping/wiki/QA-for-turn-lane-data > > Thank you Meg. > > Regards, > Greg > > _______________________________________________ > Imports mailing list > impo...@openstreetmap.org > https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
