Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Paul Johnson]

On Tue, Aug 2, 2016 at 10:59 AM, Clifford Snow 
wrote:

>
> On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  wrote:
>
>>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.
>>
>
> Frederik, I thought you were for only add objects that can be surveyed on
> the ground? Isn't that what they are proposing?
>
> We tell people not to map for the renderer. In the same spirit shouldn't
> we tell people not to let the limitations of the editor stop them from
> mapping?
>

I tend to agree, particularly for pedestrian modes.  Sidewalks and
pedestrian crossings are pretty easy to verify even from the air and this
will be at least rational for most automated routing systems and a good
starting point (even if it means multiple ways per street, short of some
form of lanes type tagging, which I think gets messy for things like
sidewalks that have a curb (or more severe) barrier).   It does give the
most reasonable routing assumption (that is, you can't just freerun
midblock from sidewalk to sidewalk).  Most routing engines will figure it
out fairly quickly if you do this anyway, however (and any highly-tuned
routing engine should be able to make an educated guess by context anyway).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

On Sun, Aug 7, 2016 at 5:04 AM, Marc Gemis  wrote:
> On Sun, Aug 7, 2016 at 12:40 AM, Greg Morgan  wrote:
>> 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
>
> Huh ? The German community had turn:lane mapping as a week project
> (don't take  that too literally) back in November 2014. Thousands of
> turn lanes have been added in the months after the idea was launched
> in "DACH" (Germany, Switserland & Austria). I had been mapping
> hundreds of them in Belgium since spring 2014, all based on the JOSM
> style developed by Martin Vonwald.
> Please do not make it sound like Mapbox pushed turn:lane mapping
> forward. Maybe this is true for the US, but not for Western Europe.
> OsmAnd has turn lane navigation since the summer of 2015.

In 2014 turn:lane mapping was not on my radar.  I have not used
OsmAnd. I had/have no clue of your activity until now.  In the last
six years I have often turned to Western Europe for examples but
turn:lane mapping has not been one of them. What MapBox has pushed
forward is excellent documentation and published it in such a way that
the documentation was clear and drew my interest.  Moreover, what
really caught my eye is how the Portland community responded to a
mistake during the mapping process.  The Portland community did not
call in the DWC to break both of the mapper's knee caps with a
baseball bat.  The issue was repaired and the community moved forward.

Regards,
Greg

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

> Again this seems to be is the "I'm waiting for someone else to do something"
> line.  If you want a map rendering that shows stop signs, create one, like I

I am not standing in any line.  If I find an issue that I don't think
has been addressed or the original author did not understand is an
issue, then I file a bug report to the best my abilities.  That
doesn't mean I have to pick up the language and supply the patch.  The
way that open source works is that you don't always have to be the
coder.  Besides I would put up Butt ugly tiles that only a mother
would dare hang on her fridge and be proud of.  Then again, Tiles At
Home was Butt ugly and effective for mappers to see there changes.
https://github.com/openstreetview/josm-plugin/issues/2
https://github.com/openstreetview/uploader/issues/5

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[ajt1...@gmail.com]

On 06/08/2016 23:40, Greg Morgan wrote:


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




Again this seems to be is the "I'm waiting for someone else to do 
something" line.  If you want a map rendering that shows stop signs, 
create one, like I did for sidewalks*.  Back in the day of hand-crafting 
Mapnik XML there was a seriously high bar to clear before "making your 
own map style", but now with CartoCSS (for which thanks, Mapbox!) that 
simply isn't the case any more.  If what you do makes sense at a local 
or national level it can get picked up at that level, and it'll stand 
much more chance of being included in one of the styles on the main 
osm.org site if you've got an example that says "here's how to do it and 
here's what it looks like"**.


Best Regards,

Andy


* https://www.openstreetmap.org/user/SomeoneElse/diary/38136

** 
https://github.com/gravitystorm/openstreetmap-carto/issues/1260#issuecomment-225009856



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Thomas Disley]

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 

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Greg Morgan]

On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  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

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Frederik Ramm]

Clifford,

On 08/02/2016 05:59 PM, Clifford Snow wrote:
> We tell people not to map for the renderer. In the same spirit shouldn't
> we tell people not to let the limitations of the editor stop them from
> mapping?

Usually, when you deal with individual mappers who come up with a
tagging scheme, you can simply let them try it because they are just one
person and the amount of stuff they can survey in any given time is
limited. Before they can break a lot, others will notice what's going
on, and a discussion can develop.

Importing sidewalks for a large city is something different. It allows
you to add thousands of objects in a short time frame. Hence the request
to "talk before you import" - something we don't expect from the hobby
mapper who adds a few sidewalks according to a tagging schema he has
made up.

> I'm not following you. They did announce their plans and are discussing
> the proposal with the community, including how to route. 

I am concerned that they might want to start importing data 5 days from
now which is certainly not enough time for a solid discussion. Maybe I
misread.

> Unlike existing routing systems, they are proposing to enable people
> with limited mobility to find a route to their location.  

As I have said, there have been a number of publicly funded projects
that had this laudable aim. Solving the issue by adding ways for every
sidewalk is one of many potential solutions; a solution that has
advantages and drawbacks which should be discussed widely before an
import is done to "kick-start" world-wide adaption of a tagging schema.

> Yet their plan is the easiest for a new mapper to follow. I've followed
> mapping of sidewalks. Where are these proposals you talk about? 

I linked some in my post to the tagging list. Some of the
failed/single-minded projects in the past didn't even bother documenting
their tags on the wiki, insofar this project is superior - and it's
totally ok for them to start a discussion. Just not an import one week
after mentioning that by-the-way-we-have-a-proposal-here ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

[Clifford Snow]

On Tue, Aug 2, 2016 at 6:01 AM, Frederik Ramm  wrote:

>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.
>

Frederik, I thought you were for only add objects that can be surveyed on
the ground? Isn't that what they are proposing?

We tell people not to map for the renderer. In the same spirit shouldn't we
tell people not to let the limitations of the editor stop them from mapping?


> 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
> of OSM (for example: what should rendering engines do with sidewalks;
> 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).
>

I'm not following you. They did announce their plans and are discussing the
proposal with the community, including how to route.
Unlike existing routing systems, they are proposing to enable people with
limited mobility to find a route to their location.

>
> Several ideas have been proposed to get around mapping sidewalks as
> individual geometries, which is in many ways the most primitive way to
> tackle the problem and the one that puts the most work on the shoulders
> of our volunteers.
>

Yet their plan is the easiest for a new mapper to follow. I've followed
mapping of sidewalks. Where are these proposals you talk about?

Your wiki page states that you had "feedback from the global OSM
> community"; I'm surprised that these details seem to have escaped you
> until now. Which sidewalk mapping experiments in OSM have you studied,
> and what have you learned? Which global OSM community did you talk to
> and where?
>

Frederik - may I suggest you comment on their proposal in a more
constructive method. I was septical of their approach when I first learned
of their plans, yet as I learn more, I've come to accept that they have a
well thought out proposal. Certainly the community should help make sure
that their proposal doesn't have some unforeseen issue. As a walker, the
current OSM sidewalk tagging scheme is lacking and just a pain when with
complex intersections. And yes I have added the entire sidewalk, manually,
to my town.

Best,
Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us