Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?

[Tobias Zwick]

Why do you think it necessary to map at all if any particular toilet is
segregated or not beyond whether I can go there as a man/woman? What is
the application?

On 24/04/2018 18:27, Rory McCann wrote:
> Hi all,

> Let's have a wee talk about how should one map gender neutral (and
> gender segregated) toilets. There is a unisex=yes for toilets which
> looks like it might be the number one tag to use. The bog standard
> meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not
> segregated into separate male & female facilities.
> 
> Many smaller public toilets are single occupancy and hence unisex, many
> larger public toilets (e.g. in shopping centers) are segregated. Social
> conservatives are mostly losing the battle on same-sex marriage, so
> their new target is trans people, and they're proposing "bathroom laws"
> to limit trans people's access to public life. Some organizations are
> making their toilets "gender neutral" in response. So there are probably
> a lot of gender neutral public toilets, and it's very useful for some
> people to know where they are.
> 
> But I don't think that's how "unisex=yes" been used in OSM. The wiki
> page says "unisex=yes" is a shorthand for "male=yes female=yes". The
> JOSM validator used to suggest that replacement, until I filed a bug[2].
> iD's preset has 3 mutually exclusive options, Male, Female and Unisex,
> it won't let you add both male=yes female=yes.
> 
> If I see "amenity=toilets unisex=yes", I would think this is a gender
> neutral toilet. If I see "amenity=toilets female=yes male=yes" I would
> think gender segregated. Big difference.
> 
> I propose that we start viewing "unisex=yes" on toilets as meaning
> "gender neutral toilet", which is different from "male=yes female=yes",
> which is "gender segregated".
> 
> Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used
> by many projects? What do they interpret it as? It's good not to force
> things.
> 
> A year ago Micah Cochran's suggestion[3] would be along these lines, but
> some changed to toilets:for:unisex=yes (etc.)
> 
> Rory
> 
> P.S. I am doing this as part of the "Diversity Quarterly Project"[4],
> which for the quarter is gendered toilets. Plenty of toilets have no
> male/female (and/or unisex) tag, and we should add those tags.
> 
> [1] https://en.wikipedia.org/wiki/Unisex_public_toilet
> [2] https://josm.openstreetmap.de/ticket/15536
> [3]
> https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements
> 
> [4] https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] "The Future of Free and Open-Source Maps" Slashdot.org , Saturday February 17, 2018

[Tobias Zwick]

I also read this article and I found it identifies some areas in which
(the central infrastructure of) OpenStreetMap could improve.

What I do not like about this article is the deeply pessimistic and
resigned tone of it, like clickbait. It reads like "OSM needs to change
from the core up or else it will be doomed!".

Yeah, I don't think so.

And I do not think that this mode of appeal is that productive. It's
good if it sparks discussions about what we can and want to improve, but
I do not think that it is going to inspire anyone to "save" OSM by
innovating things. This is not how it works in FOSS, and not how
innovation works. AI detections of features from pictures/drone videos
for example is not going to happen because someone writes that we
_really_ need this now to keep up, but because someone is enthused about
the concept (and is able to capture others with that).
Also, Serge maybe doesn't know
https://blog.mapillary.com/update/2015/01/27/traffic-signs.html

That there might be a conflict of interest regarding pulling more
technology and services into the core OSM toolset is an interesting
thought that did not cross my mind before and that may very well be
true. Though on the other hand, I consider the fact that OSM runs on a
"shoestring budget" as something that contributes to OSM's
sustainability: I.e. I observe with concern that Wikimedia apparently
requires more and more money every year to survive.
OSM's minimalistic organizational structure is simply a different
concept than WP.

Regarding the "area" type, I agree that it would be a good improvement
to introduce a more fixed notion of areas in OSM data. To introduce
another data type has quite the ramifications on backward compatibility
but there may be other options. Right now, every single piece of
software needs to maintain an area detection based on tags like this:
https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/meta/OsmAreas.java#L13-L28
Naturally, it is different, thus inconsistent, for any piece of software
- and needs to be updated for any tagging scheme that comes up.

If I were to name the biggest challenge for us, it would be the
maintainability of the map data, a topic that he never mentions directly.

Tobias

On 17.2.2018 10:56 AM, Oleksiy Muzalyev wrote:
> This article is on the front page of the Slashdot today:
> 
> Fri 16 February 2018 "Why OpenStreetMap is in Serious Trouble"
> 
> https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/
> 
> 
> "The Future of Free and Open-Source Maps"
> 
> https://news.slashdot.org/story/18/02/16/2216228/the-future-of-free-and-open-source-maps
> 
> 
> 
> I actually read the article, and though it has got insightful
> information and interesting ideas, I have doubts about some suggestions.
> 
> For instance, reviews. I hope it will not come to what there is at some
> commercial maps, when one adds say a building and then has to wait for a
> month that an almighty moderator approves it, so that it appears on the
> map.
> 
> I also skeptical of massive imports from governments' databases. These
> databases were created in the last century, with outdated tools,
> sometimes by disinterested underpaid clerks, probably in a climate of
> secrecy of that era. And such an import may replace the quality data
> from modern satellite imagery, GPS traces, surveys, etc.
> 
> Best regards,
> 
> O.
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Tobias Zwick]

This is how StreetComplete does it. Good thing is that the OSM server
automatically closes changesets where nothing was added after one hour,
so one does not need to worry that a changeset gets "stuck" if the user
exits the application without closing the changeset.

On 17/01/2018 18:47, Rory McCann wrote:
> On 17/01/18 15:13, Michał Brzozowski wrote:
>> Certainly not:
>> - one changeset per building, repeated 20 times
> 
> Couldn't this be done with the "upload" vs "new changeset" feature of
> the OSM API? A technical solution. Multiple uploads in a single changeset?
> 
> Users want to save/upload frequently (because computers), so we'll never
> stop them pressing the button often. Maybe iD could keep a changeset
> open and an upload rather than open a new changeset? There would have to
> be an option to "close current changeset and open a new one" (& close
> current changeset), and to word that in a more friendly way for people
> who don't know the terminology.
> 
> I don't think linking to documentation will solve this issue. Too many
> users don't read things like that, no matter how much we'd want them to.
> 
> Yes, I know I'm suggesting a software change without offering a patch.
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] How to teach novices about optimal changeset size?

[Tobias Zwick]

So, what is the optimal changeset size, and why?

Tobias

On 17/01/2018 14:26, Michał Brzozowski wrote:
> Many new users have a habit of e.g. sending one or few objects per
> changeset, resulting in a dozen or even more changesets per day.
> Obviously this makes them PITA to review quickly in Achavi or whatever
> tool you use.
> 
> This habit is probably caused by non-knowledge of how auto-save works in
> iD (which makes the work reasonably secure), as well as just not knowing
> better thus forming their own judgement.
> 
> How should we teach about optimal changeset size? This is quite tricky -
> how we would define it?
> 
> Can the iD nudge users towards better practice? (Linking to Good
> changeset comments wiki page would be useful as well)
> 
> Michał
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk] Tool for tag tracking

[Tobias Zwick]

Wow, Roland, this is awesome!

So, this seems to make any deliberations of introducing a
survey_date:something tag or similar obsolete, because in the future,
one will be able to search with overpass through the history on a
per-tag basis.

This will make it possible for QA and hm... data-actuality-maintenance
tools (made up this term, this category of tools doesn't exist yet I
guess) to find data that haven't been changed for a long time and should
be re-checked some time.
I am thinking of finding automatically certain data points (tags) that
haven't changed in the database for X months and should be re-surveyed.
Will that be possible also (checking for "last change on tag older
than...")?

This feature makes it possible to greatly improve the maintainability of
data in openstreetmap.
For example the smoothness of streets and cycleways in particular is
something that should be revisited every few years, same as the street
surface especially in developing countries. Also, the presence of
cycleways on streets might be something that should be re-checked every
decade or so at least. Etc etc

Great work!

Cheers
Tobias

On 12/01/2018 06:31, Roland Olbricht wrote:
> Hi,
> 
> for the sake of completeness, I would like to give a preview what is in
> the development for Overpass API:
> 
> Similar to this one
> 
>> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass
>>
> 
> you could nowadays search with https://overpass-turbo.eu/s/uF0
> for all highways that have changed since the beginning of the year in
> and around Antwerp:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> out geom;
> 
> I suggest the "out geom" mode over recursing to the nodes. Overpass
> Turbo can handle both, but the "out geom" means that there is exactly
> one item per object in question. No unchanged nodes get involved.
> 
> The above result is bloated by objects like
> https://www.openstreetmap.org/way/469659128/history
> It has no change to its highway value but just lost the unrelated tag
> "horse=no".
> 
> Here comes a feature in the staging area for the next version into play.
> We do not ask for all changes but just for changes that affect the tag
> "highway": https://overpass-turbo.eu/s/uF2
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:t[highway]);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> The line "compare(delta:t[highway]);" reads as: keep only objects that
> have changed in the value "t[highway]". The last line is a directive to
> execute the query on the development server.
> 
> We could even drill down further and retrieve only objects that have
> been created or deleted: https://overpass-turbo.eu/s/uF4
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> This is admittedly hacky and the final implementation might have a more
> straightforward term. The condition for "compare" always evaluates to
> the empty string for non-existing objects. And for existing objects to
> "0" as we just have specified, hence it can tell apart existing from
> non-existing objects.
> 
> Can we separate the deleted from the created objects? Yes,
> https://overpass-turbo.eu/s/uF7 delivers only created objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   way._(newer:"2018-01-01T00:00:01Z");
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> And https://overpass-turbo.eu/s/uFa delivers only deleted objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> Please note that these are not yet in a published release because there
> may come up a reason to change the syntax. If that happens, I will write
> a mail here again. For example, it might be more concise to do these
> tasks with a three argument "changed" condition. But I have not
> evaluated yet whether this leads to a logically sound syntax.
> 
> Best regards,
> Roland
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

[OSM-talk] Mapzen is shutting down

[Tobias Zwick]

Hey guys

Some of you already read it on weekly, Mapzen is shutting down. This is
very sad news for the new year, as they were working on many promising
open-source services around OpenStreetMap.
I don't have the best overview, but their main product was the vector
map, so amongst the most important projects were

+ tangram and tangram ES (GL vector maps for web, embedded, mobile etc)
  https://github.com/tangrams

+ vector-datasource (Vector tile service)
  https://github.com/tilezen

+ Valhalla (routing engine)
  https://github.com/valhalla

+ Pelias (geocoder)
  https://github.com/pelias/pelias/

(did I forget anything?)

With the company being in dissolution and the developers forced to find
other jobs, all the work done in the last few years might be for the
birds if these repositories will no longer maintained.

I read we do not have to worry about the Valhalla team and project, they
found a new home at MapBox.

Also, I read today that the maintainers of Pelias announced this week,
that they will not shut it down. Full statement here:
https://github.com/pelias/pelias/tree/master/announcements/2018-01-02-pelias-update

But the future of Mapzen's main product, both the vector tile server and
tangram is what I am worried for. With Mapzen's tile services shutting
down along with everything else, the demos [1] will not work anymore and
people who want to use tangram will need to set up an own tileserver for
that, which is something the fewest would do with the easy alternative,
MapBox (and others? Or are there no more other competitors?).

Perhaps some people from the team/company are on this list and can share
their view on how or if these projects can continue and maybe how we as
a community could help.

Greetings
Tobias

P.S: Not sure if I should post this also on the dev mailinglist?

[1] http://tangrams.github.io/tangram/

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

> compromise between the two, how about I disable the "embed edit".  If
> the query is executed from a link, without the query editor mode, users
> can only view results.  But in the power mode, the users can still use
> the tool to write a query they need, test and edit things as they need. 
>  So its ok to use it as a power editor (e.g. JOSM or Level0), but not as
> mass contribution.

I like this idea, that also goes into the right direction.
Something like this is what I had in mind when I said the tool should
not lend itself for a purpose it is intended for (mass re-taggings
without prior discussion and consensus).
> In the mean time, I will add the "two person approval required", which
> should alleviate expressed concern.  Should be ready fairly soon.

+1
A reject feature plus a two-person approval feature sounds like a
solution with which noone should have a problem with the tool thereafter.

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

I get your point, especially regarding the appliance of the JOSM
fix-button as a "by-the-way" fixing.

Though, you can't fix possible issues with of one tool by introducing
another tool. People will not stop using (that feature of) JOSM. That is
why I think, if you think you detected a problematic issue there in that
editor, it should be discussed in a separate topic.

On 17/10/2017 00:57, Yuri Astrakhan wrote:
> Michael, I can only judge by my own experience adding validation autofix
> rules - I added a number of Wikipedia tag auto cleanups to JOSM, and
> they were reviewed by one or two JOSM developers and merged, probably
> because they were deemed benign.  I don't know about the other rules,
> but I suspect many of them also went this route.  Should have they been
> discussed more widely? I don't know, but that question is complicated,
> just like "what is a local community?" question. What a few devs may see
> as benign, others may say needs a discussion, right?
> 
> Mass editing is a different matter.  We consider mass editing when one
> person goes out to fix something everywhere in the world.  But when we
> provide a tool that automatically fixes something that you are looking
> at, we don't view it as such.  Or at least we don't view it when it
> happens as part of JOSM, but we do when it happens in my new tool. Of
> course there is an important difference - JOSM doesn't guide you towards
> those cases.
> 
> I think massive "by-the-way" fixing is far worse than the targeted fix
> of a single issue.
> 
> When you want to fix a single issue in many places, you become a subject
> matter expert.  You know all about that change, how it interacts with
> other tags, what to watch out for, how to handle bad values, etc.  For
> example, when fixing wikipedia tags, you would see the types of mistakes
> people make, wrong prefixes people use, incorrect url encodings, hash
> tags in urls, incorrect multiple values, ... .    When you simply click
> "fix" because JOSM validator tells you it can fix it automatically, you
> don't have that knowledge, so it effectively becomes a distributed
> mechanical edit without the "reject" capability.  My tool tries to
> address this - to build domain experts in a narrow field, and let those
> experts review changes one by one. I do not discount the value of local
> knowledge, but it is not a panacea - you must be both to make
> intelligent choices, and in some cases, the domain knowledge is more
> important than the knowledge of a specific locale.
> 
> On Mon, Oct 16, 2017 at 4:00 PM, Michael Reichert
> mailto:osm...@michreichert.de>> wrote:
> 
> Hi Yuri,
> 
> Am 16.10.2017 um 16:02 schrieb Yuri Astrakhan:
> > Rory, most of those queries were copied from the current JOSM validator
> > autofixes.  I don't think they were discussed, but they might have been
> > mass applied without much thought by all sorts of editors.
> 
> Could you please give examples for (a) the mass appliance of these rules
> and (b) rules which have not been discussed but should have been
> discussed?
> > There are two ways to use the tool - you can write your own query, run 
> it,
> > and fix whatever it is you want to fix. That's the power user mode -
> > anything goes, no different from JOSM or Level0. And there is another 
> one -
> > where you go to osm wiki, read the instructions, find the task you may 
> want
> > to work on, and go at it.   The community reviews wiki content, tags
> > different pages with different explanation or warning boxes, etc. The
> > discussion could still be on the forum, or here, or in IRC, 
> 
> Just for future readers: IRC and Telegram channels are no replacement
> for a mailing list or a forum with a public readable archive where you
> can look up the discussions years later.
> 
> 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)
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

>> Anyway, generally, with everyone raising the alarm about this tool, it
>> would be a friendly gesture to either take the tool offline for now or
>> set it to read-only mode
> 
> Or have it run on the dev API.

Does the dev API have real (=mirrored) data?

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Number 2.

>> [...] This was a topic in this thread already and it was
>> voiced that inventing new tags just to be used by this tool in not
>> acceptable and I agree with that. The other tools also do not
>> require that.
>
> [...] Not showing it can also be easily done by a slight
> modification of the query itself.  This is assuming my reasoning for
> on-OSM tag storage makes sense for other tools. In the mean time, I do
> plan to make a separate reject storage system just to cover all cases.

An on-OSM tag storage? Inventing new tags for (single) tools is
specifically what I mentioned has been strongly opposed!

I see you mention having some OSM tag further below in your message and
you give some arguments why this might be a good idea beyond the ease of
implementation.
I'd say, of course whether such a tag or namespace of tags could make
sense is something that can be discussed. But not after the fact and not
on pressure. Your tool being live, and no way marking something as
false-positive, this does set a discussion about this in exactly in a
bad atmosphere.
Anyway, generally, with everyone raising the alarm about this tool, it
would be a friendly gesture to either take the tool offline for now or
set it to read-only mode (no save button) so that everyone can calm down
and the critical points about it can been addressed and solutions be
found, in an objective non-pressured manner. Since this is a general
consideration that concerns other tools as well then, it should be done
in a separate topic.

Anyway. I am surprised to read that you see the tool actually also in
case #1, as a manually operated automatic edit. It could be that I, and
probably many people here in this topic majorly misunderstood your
intention with this tool.
Let me summarize your arguments why this makes sense over a fully
automated edit:

1. barrier too high for writing a completely automatic bot
  a) automatic edits are too risky, fear of programming errors
  b) too thorough review is required for fully automatic edits, fear of
 uncovered edge cases
  c) a mistake of a bot edit can only be spotted after the fact and a
 (partial) revert of such a bot edit is complex

2. your tool lowers that barrier by creating some kind of staging / test
   area for bot edits by having different users manually confirm or
   reject the proposed fix for any such element
  a) it's relatively easy to add an automatic edit to the tool and that
 same query can be used to run directly on the server for full
 automation
  b) issues with the query can be fixed by anyone (wiki)

---

I can follow your line of argumentation and your vision. There is quite
the discrepancy between this and the concerns mentioned so far in this
topic, which see your tool from a different perspective (which I will
iterate further below).

The concerns are, that the tool will not actually be used to
stage/analyze the impact of an automatic edit that is to be applied
after consensus and thorough testing but to go forward with organized
re-tagging without that (or at least give other users the tool to do
that). If this is not your intention, then the tool must be changed in a
way that it does not lend itself for that purpose.

Furthermore, the argument that a mistake in a completely automatic bot
is complex to revert, seems bogus. If the edit happens in *one* edit, it
is on the contrary, very easy to revert. If, on the other hand, dozens
or even hundreds of people worked on a quick-fix task which needs to be
reverted, again on the contrary, this is much harder to revert because
there are different users, different changesets and over a varying
timespan involved. (Also, I hope the tool at least writes into the
changeset which quick-fix exactly was used, to link quick-fix with
changesets)

> [...] this will be up to the communities to enforce - if
> someone writes a query [that requires actually going there to check],
> others should be quick to point this out.

Better, document that. Here, look for example at the guidelines for new
"quick-fixes" (aka quests) I wrote for my OSM tool:
https://github.com/westnordost/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete

Leaving this kind of supervision to "the community" means that you
generate thankless work for people that constantly "should be quick to"
sound the alarm for quick-fixes that are not correct in one way or the
other (which are immediately live).

Not sure if this came across to you yet, but it has been said a couple
of times in this thread already and it should be repeated in light of
the answer you gave above:

When you say, it is up to the community to point out problems with any
such query that has already been created and is being worked on, then
you basically reverse the whole guidelines for bot-editing - the
community learns about it after the fact, instead of before it is
happening. This is exactly the situation we do not want to have.
This is the fundamental issue with the tool and something t

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

I will split this into several answers, that is what a threaded
structure is for.

> JOSM fix button

I am not sure what is your point with JOSM's fix button. Let's not
deviate from the topic: your tool.
If you find, something is wrong with JOSM or any other tool in that
matter, better create an own topic for that. In any case, it is not a
good argument to justify deficiencies of one tool with deficiencies
another tool might (or might not) have. Not saying that this is your
intention here, what I understood is that you want to say that the idea
for your tool mainly comes from wanting to improve on the idea behind
that feature in JOSM. Ok.

> it won't save unless you zoom in to 16+ (just like iD editor).
> Plus I added Mapbox satellite imagery to help.

You mean, the save button is disabled, right?

> MapRoulette and SPARQL

Well, if you are not interested in getting involved in MapRoulette to
add your idea there, that's your choice. I am elaborating below just to
get this clear, in case you misunderstood:

I did not mention SPARQL. I was talking solely about the idea of
quick-fixes, not to transplant your current code into MapRoulette.
Naturally, the implementation in MapRoulette would not include SPARQL
queries but i.e.

1. the creator of a challenge simply supplies the "quick fix" answer
   option(s) in a multiline textfield after he supplied the Overpass
   query, i.e. like this:
   sport=soccer
   sport=american_football
   sport=canadian_football
   sport=australian_football
   sport=gaelic_football

2. MapRoulette shows the answer option(s) (as dropdown) next to the
   other buttons for each element in the challenge.

3. MapRoulette uploads the selected quickfix through OSM API

I was also bringing this up, because I was quite shocked to see how much
code is necessary in SPARQL just to convert

  religion=Christian into religion=christian
  (http://tinyurl.com/yame4thf )

I am already lost there with this query. I'd say, as a user, it is
*really* easy to make a mistake there.

>> Though, note, for all three cases, a prior consensus is required,
>> either by prior discussion or by looking at what was previously
>> agreed on in the wiki. That is the case for *any* organized
>> re-tagging of existing tags.
>
> Sure thing. There are very very few cases when the fix is super
> obvious, e.g. a typing fix, but lets not dwell there.

In regards to what I said above, I reckon you can do a lot more stuff
with SPARQL than simple tag replacement. Fair enough, that I'd find such
an extension of MapRoulette more useful is just my personal opinion.

Tobias

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

> Except that's not true. In Ireland "handball" is Gaelic Handball¹
> which is a one-on-one game, not a team sport (which is apparently a
> different thing²). There are some sport=handball's tagged in Ireland.
> Now the tag is clearly wrong, and we need to figure out something about
> that. But if you just change sport=handball to sport=team_handball, then
> you've entered incorrect data, based on incorrect assumptions.

Good catch. So, it is no good as an example for that. But no matter, I
think the idea got across anyhow.

> Big question: What defines "community consensus"?

I can't really answer that. I'd define it as "Topic has been brought up
to the public and there are no justified and irrefuted objections."

> Not everyone (incl me) thinks that the wiki defines what a tag should
> mean...

Sure, the wiki is to be taken with a pinch of salt (I think I do not
need to elaborate why), but it is the only documentation we have.
Everyone, (new) users, data consumers and app developers simply will
always consult the wiki.
Because the wiki has such a central importance, the (unwritten?
written?) rule is that parts that explain what has to be mapped how
should only be done to document the status quo (if it is explicitly
stated as such) or better after finding such a consensus.

Tobias

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

Re: [OSM-talk] New OSM Quick-Fix service

[Tobias Zwick]

Hi Yuri

I am not aware of the record of your previous interactions with the
community and I think you cannot be blamed to not respond to any toxic
feedback and/or accusations thrown at you here, whether they may be
justified or not.

So, I give you the benefit of the doubt and write up this honest and
constructive feedback. Substantively, I come to the same conclusions as
the previous posters: That I find it hard to see that the app will have
any positive impact - at least "as is". I hope you value it nonetheless,
I also have some suggestions at the end.

So, the initial question is: What is the conceptual use case for such a
tool? Where would be its place in the range of available OSM tools?

There is the use case where one tagging scheme has been deprecated by
community consensus and one (combination of) tag(s) should be changed
into another (combination of) tag(s) globally.

1. If this does not require humans because both tagging schemes are
mutually translatable (i.e. lets say for sport=handball <->
sport=team_handball), then, the edit can be made automatically by a bot.

2. If this does require humans to check the transition to the new tag
because the deprecated tagging scheme is ambiguous (i.e. , such as
sport=football -> soccer or american/australian/canadian/... football),
then, an automatic edit cannot be done. Instead, tools like MapRoulette
are used.

3. Finally, if this also does require humans because a tag combination
is suspicious (what would show up as warnings in JOSM and what most of
Osmose consists of), also, a tool like Osmose or MapRoulette is used.

Though, note, for all three cases, a prior consensus is required, either
by prior discussion or by looking at what was previously agreed on in
the wiki. That is the case for *any* organized re-tagging of existing tags.

I reckon you see the quick fix tool to be in category 2 and 3 here,
along with MapRoulette and Osmose, only with the crucial advantage of
being quicker to use, since no editor is required.
But it seems to me, you didn't think this through. If the tool offers
*one* solution to any re-tagging ("Save" or leave it), then, this is
pretty much a manually operated automatic bot (case 1), which really
doesn't make sense. For case 2 and 3, it cannot be used as is, because:

- Quick fix cannot be used to find what kind of football it is (case 2),
but MapRoulette can, because it leaves the actual editing to the user.

- Quick fix cannot be used to solve any markers which may or may not be
an actual problem (case 3) because it has no way of marking any of the
things as false-positives.

Looking at your linked Wiki document (
https://wiki.openstreetmap.org/wiki/Quick_fixes ), most of these are
candidates for automatic corrections. I.e.:
- Convert religion=Christian to religion=christian
- Convert various common forms of religion=catholic to
religion=christian + denomination=catholic
- Convert religion=islam to religion=muslim
- etc.

(Only) your initial example ( amenity=sanatorium -> leisure=resort +
resort=sanatorium for ex-USSR-countries) falls in case 2. But then, as
mentioned, either marking as false-positives or other answer options
(i.e. "yes, it is a sanatorium in the West European sense") are missing.

Okay, so much for why I think the tool is, as is, not fit to be used and
probably why you got so many negative responses here.

*However*, the idea as such, to make the clean-up process of either
clearly wrong tags, deprecated tags or even just warnings
semi-automatic, is a very good one. The prerequisite is, that there must
always be the option to *not* apply that fix and save that decision. The
other very critical point is, that the easier you make it for users to
apply a predefined fix, the more precautions must be taken to ensure
that the user really checked the situation.

So, the most critical missing features from my point of view in your
tool are

a) There must be an option to manually edit this instead and/or marking
it as a false positive. In any case, the marker may not be shown for
other users anymore. This was a topic in this thread already and it was
voiced that inventing new tags just to be used by this tool in not
acceptable and I agree with that. The other tools also do not require that.

b) I strongly suggest to offer different answer options. As I said, if
only one option is available, it is really nothing else than a manually
operated automatic edit. If several options are available (i.e.
"american football", "soccer" etc. ) as a quick fix, only then the tool
becomes to be useful. (There are some challenges like that on
MapRoulette also, such as "Phone or fax number is not in international
format" and these in my opinion also do not belong there because they
can be solved automatically)

c) Require users to zoom into the map at around zoom 17 or more to make
any changes. If the users are supposed to check if something is the case
(via satellite image), then at least don't let them cheat by just
solving everyt

Re: [OSM-talk] StreetComplete v0.14

[Tobias Zwick]

> Would it be possible in a future version to allow the user to filter
> out certain types of quests?

Yes it would. This is my next big item on my TODO list, there is also an
issue for it on GitHub.

> method to maintain the data quality in OSM to make it less likely that
> data becomes out-of-date

I would say so. What is needed to enable quests like "Is this X still
there?", "Is this railway stop still not wheelchair accessible?, "Are
these opening hours still correct?" etc. are three things:

1. possibility to query elements - or rather single tags of elements -
   by last change date via Overpass. The former is already possible, I
   read

2. possibility to record that an element - or rather a single tag of an
   element - has been surveyed at a date and no change was required

3. just a little research about the usual lifetime of different
   map features / tags, so that users are not bothered about rechecking
   things too often


On 13.7.2017 1:46 PM, Svavar Kjarrval wrote:
> Thanks for the app. Will test it out soon on the ground.
> 
> Would it be possible in a future version to allow the user to filter out
> certain types of quests? The one most prominent in my neighbourhood is
> the type of road surface and due to the amount of roads I'd rather take
> care of it on a desktop computer. Other possible scenarios is that the
> user might want to ignore that type for other reasons or to get a break
> from it. Such an UI option could also give the opportunity for opt-in
> quests, which are generally not interesting to the general user but
> would allow the OSM nerds to collect more unusual information.
> 
> One of the ideas I put forth on (I think) this mailing list was that we
> needed a method to maintain the data quality in OSM to make it less
> likely that data becomes out-of-date, for example opening times. I don't
> know if it would fit within the scope of the StreetComplete project, but
> it's worth a thought.
> 
> - Svavar Kjarrval
> 
> On mið 12.júl 2017 17:01, Tobias Zwick wrote:
>> I am proud to announce that after a long public betatest, the first
>> stable version of the app has been released on Google Play and F-Droid.
>> StreetComplete is a FOSS Android app that aims to enable easy on-survey
>> contribution to OSM for anyone.
>>
>> Specifically, it enables users to extend already mapped data through a
>> simple question-answer format: The app ask questions about things on the
>> map  such as "What is the name of this road?" or "How many levels does
>> this building have?" and the user is given a simple form to fill in this
>> information.
>>
>> The processed answers are then directly uploaded as changes to the
>> OpenStreetMap, eliminating the need to (learn and) use another editor
>> for simple contributions.
>>
>> In this first version, the following quests are implemented. Users can
>> contribute:
>> - road name
>> - road surface
>> - to note discussion (only notes that contain a question are shown)
>> - opening hours
>> - bike parking capacity
>> - bus stop shelter
>> - building and roof levels
>> - roof shape
>> - sport played on a pitch
>>
>> More are in the works for the next version.
>>
>> For more information, check out the project's GitHub page
>> (https://github.com/westnordost/StreetComplete) or search for it in the
>> app store.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

[OSM-talk] StreetComplete v0.14

[Tobias Zwick]

I am proud to announce that after a long public betatest, the first
stable version of the app has been released on Google Play and F-Droid.
StreetComplete is a FOSS Android app that aims to enable easy on-survey
contribution to OSM for anyone.

Specifically, it enables users to extend already mapped data through a
simple question-answer format: The app ask questions about things on the
map  such as "What is the name of this road?" or "How many levels does
this building have?" and the user is given a simple form to fill in this
information.

The processed answers are then directly uploaded as changes to the
OpenStreetMap, eliminating the need to (learn and) use another editor
for simple contributions.

In this first version, the following quests are implemented. Users can
contribute:
- road name
- road surface
- to note discussion (only notes that contain a question are shown)
- opening hours
- bike parking capacity
- bus stop shelter
- building and roof levels
- roof shape
- sport played on a pitch

More are in the works for the next version.

For more information, check out the project's GitHub page
(https://github.com/westnordost/StreetComplete) or search for it in the
app store.

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

Re: [OSM-talk] Street Complete

[Tobias Zwick]

> I guess, having your app publicly denounced as "StreetComplete - the
> next plague [to hit OSM]" (as the original thread title suggested before
> mods intervened, see #10) is giving developers a huge incentive to spend
> more time on their OSM related spare time projects.
> 
> I seriously hope that this not becoming the new role model to get things
> fixed in OSM related apps.

Are you suggesting that if the feedback would not have been as abusive
as it was, I would not have implemented it?

This makes me angry.

Rudeness and contempt for other people's work is never constructive. It
actually cost me quite an effort to react calm and sensible in that thread.

What should not become the standard is the false assumption that this
kind of conduct is in any way helpful.

Tobias

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

Re: [OSM-talk] Street Complete

[Tobias Zwick]

> Did these two notes get created by the application? I installed
> StreetComplete to try and reproduce the behaviour before realising
> I'd manage to add surface tags to a few local roads.
>
> https://www.openstreetmap.org/note/1016204
> and
> https://www.openstreetmap.org/note/1016625

When a user is unable to answer a question, he is given the choice to
either hide the question or leave a public note. If he chooses to leave
a note, he is prompted to write a note ("You can leave a public note at
this location which other mappers can comment on and hopefully resolve")
in which he can specify why this question cannot be answered.

So, only in this case, a note is created. And it is not created
automatically, it is created by the user. The app only adds context by
appending the question the user was asked and the link to the associated
element.

Usually the reason for not being able to answer a question is that the
question is based on now wrong data, such as in your links that the
location does not exist (anymore).

Talking about non-obvious features,... creating notes is not a one-way
process by the way. If a note contains a question (mark), StreetComplete
surveyors will see the note and be asked to contribute to it. So,
at-home mappers and people doing QA can direct questions at people in
the field.

---

Apparently that the question is being included in the note leads to some
confusion. Perhaps it makes sense to change the wording to something like:
"Unable to answer "How many bicycles can be parked here?" for
https://www.openstreetmap.org/node/254643604 :

There is no cycle parking here."
?

Tobias
(Author of StreetComplete)

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

Re: [OSM-talk] Street Complete

[Tobias Zwick]

> After Ihad entered the choice as an experiment I was expecting a note to =
appear

Really? That behavior would be horrible!

Please read the description of the app on Google Play, F-Droid or=C2=A0GitH=
ub, then it should be clear what the app is doing. It says:

"This app finds incomplete and extendable data in your vicinity and display=
s it on a map as markers. Each of those is solvable by answering a simple q=
uestion to complete the info on site.

The info you enter is then directly added to the OpenStreetMap in your name=
, without the need to use another editor."

> Thatis sensible to me, why would a short ( It also seems to have changed =
a pedestrian to a service because it has no name, again quietly.

It changed it into a service road because on "What is the name of this stre=
et?" you answered "It is not a proper road" and then "It is just a service =
road".

> Lint tools in general suffer from the problem that some people assumethey=
 are errors and fix them without checking. This app has the benefit
> of being a lint tool that you can carry around and check because you're
> there.

I think the main misunderstanding here is the assumption that StreetComplet=
e is a lint tool. It is not a lint tool, it is a surveyor tool.

Tobias
(Author of StreetComplete)

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

Re: [OSM-talk] Finding duplicate cycleways

[Tobias Zwick]

Hey Roland

The reason I asked about whether there is a tool that finds (possibly
wrong) duplicate mapped cycleways because a very similar algorithm could
be used to determine whether any one street is actually *missing*
cycleway tagging or whether the cycleway is in fact already tagged but
as a separate way.
In other words, I need all those roads that neither have a cycleway=*
tag (easy) nor have a cycleway-way next to them (the hard part). I
wonder, is this possible to achieve with an Overpass query?

I was told here
https://github.com/westnordost/StreetComplete/issues/139#issuecomment-297518195
by an Osmose-backend contributor that they implemented this already, but
of course, Osmose does direct postgis queries, so more is possible with
this.
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_cycleway_track.py

I am developing an app with which one should be able to map cycleways
basically by simply answering the question "Is there a cycleway here?"
and of course, the app needs to find out, where it may ask and where it
shouldn't.

Greetings
Tobias

On 28.4.2017 6:36 AM, Roland Olbricht wrote:
>> http://overpass-turbo.eu/s/oEm
> 
> Thank you for the link.
> 
>> Unfortunately it does not (yet)catch also the segregated and
>> not-segregated foot-cycle-paths that are tagged using the JOSM presets
>> (highway=path, foot=designated, bicycle=designated, segregated=yes|no)
> 
> http://overpass-turbo.eu/s/oG6
> 
> I have essentially just added the conditions you mention in one line. I
> have slightly changed the viewport to have relevant results for the
> change within the viewport.
> 
>> I am not an Overpass-Turbo expert and don't dare to add them to your
>> script
> 
> The linked queries are immutable. If you open the link then you always
> work on an independend copy.
> 
> Cheers,
> 
> Roland
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Finding duplicate cycleways

[Tobias Zwick]

> https://www.google.com/maps/@47.6757218,-117.3849352,3a,75y,70.4h,83.24t/data=!3m6!1e1!3m4!1sqdzvokjXjkutvCYJLOWh_A!2e0!7i13312!8i6656!5m1!1e4
> 
> That's a bicycle lane on the road, plus a distinct bicycle path running
> parallel to it.  It's mapped in OSM as a "cycleway=lane" on the road and a 
> "highway=cycleway" running parallel to it.

Okay, I mean of course duplicate cycleways where the duplicate mapping
is an error. Correct usages like you present can be filtered out by
looking a the value of the cycleway tag: If there is a separate way and
the cycleway-tag on the road is a track, then it is probably an error.

> do you suppose this is an error?

I would say so, as long as there are not in reality two cycleways (see
above). Wouldn't you?

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

[OSM-talk] Finding duplicate cycleways

[Tobias Zwick]

Hi

I wonder, does anyone know a QA tool out there that finds duplicate
cycleways?

With duplicate, I mean cycleways that are both
- tagged as cycleway=* on a highway=* way and
- mapped as a separate way parallel to the street with highway=cycleway

I understand that there is no simple tag on the highway=* way to denote
that the cycleway is mapped as its own way, so whether a cycleway is
mapped or not cannot be determined just by looking at the tags of a road
but must be determined by analyzing the geometry of ways in relation to
each other (I guess).

Greetings
Tobias

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

Re: [OSM-talk] Beware Pokemon users

[Tobias Zwick]

To have a gamified way to contribute to OSM was my original idea for
StreetComplete[1]. There should be leaderboards, badges/achievements
and different stats, also different quest givers/categories each with
own pictures (like i.e. on WikiMapia), a possibility to form teams and
compete with each other for "dominance" (=contributing most) in cities.

So the game itself would (still) be to directly contribute to OSM itself
but I think this is a good enough basis for a gamey app.

For StreetComplete, it currently develops more into the direction of a
surveyor app, but only because I want to get the basics working first,
so everything is no-frills.

Tobias

[1] see https://github.com/westnordost/StreetComplete

On 30.12.2016 9:43 PM, moltonel wrote:
> 
> 
> On 30 December 2016 18:50:17 GMT+00:00, Paul Johnson  
> wrote:
>> What's the elevator pitch for Kort?
> 
> http://wiki.openstreetmap.org/wiki/Kort_Game
> 
> It's a gamified way to edit osm, which is good  but unlikely to attract 
> non-OSMers. I'd like something that is more geared towards gamers but still 
> directly usefull for mappers.
> 


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

Re: [OSM-talk] Key:Destination Abbreviations

[Tobias Zwick]

Hey Edwin

I read through the discussion on that page.

I think you focus too much on this 20:1 statistic. I too think this does
not really belong on the main page, but this is not really the issue.

I do not have the impression that anyone is using the 20:1 statistic as
an argument whether the destination name should be abbreviated or not.
The argument is that abbreviations in names being expanded for the DB is
the standard _in general_ and that the destination-value is just another
name(-like) tag.
Which I can totally follow. After all, where is the difference between a
sign on a freeway saying "Argument Ave" for the next exit and an actual
street sign at an intersection saying "Argument Ave"?

Why should this one sign not be abbreviated (street name) but that other
sign (freeway exit name) should?

As Carciofo said on the discussion page, I don't see the use case why
this consensus on names should be overturned for a specific tag.
You mentioned so that the actual sign could be displayed by the
navigation software. Well, it still can, the software just needs to know
how to abbreviate words, which is easy to do. The other way round,
automatically expanding an abbreviation (i.e. reading aloud) may be
ambiguous.

This is an old argument, it has been brought up years ago when talked
about whether to abbreviate names or not in general. That the same
argument applies to Key:destination again is a clear sign that
Kay:destination is in fact just another name tag.

Cheers
Tobias Zwick

On 18.12.2016 10:40 PM, Edwin Smith wrote:
> Hi all,
> There is a disagreement that could use a few more eyes.  Destination has
> the explicit purpose of telling a
> navigation program the wording of a sign.  It is typically used as a tag
> of a Motorway Link.  It is not visible
> in the Mapnik in any way.
> 
> One side of the disagreement argues that if an abbreviation appears on
> the sign (Ave for instance)
> it should be expanded to Avenue in the Destination Tag.  The arguments are:
> 1) OpenStreetMap discourages abbreviations
> 2) If you search through Destinations every time Avenue appears it is a
> mapper vote for expanding Ave to
> Avenue.
> 
> The other side of the disagreement (which I support) argues to present
> the sign to the navigation program
> exactly as it appears, neither abbreviating or expanding abbreviations. 
> The arguments are:
> 1) Destination is for the use of the navigation program.  If
> abbreviations are changed it has no way to
> know if the sign says Ave or Avenue.  If they are unchanged it can make
> its own decision as to what use
> of abbreviations is best for its users.
> 2) It is just wrong to count every Avenue as a mapper vote for expanding
> Ave because it very often is
> just the mapper's correct reporting that the sign has Avenue spelled out.
> 
> Check it out in the Key:destination Discussion.  As you will guess, the
> EDSS comments are mine.
> 
> Cheers,
> Edwin Smith
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk] Mozambique's living streets

[Tobias Zwick]

> from minor ones... Some bright spark took initiative by tagging a large
> part of Dakar's residential streets as highway=service - that has been
> universally perceived as a very bad idea.
Well, there is this line in the wiki for highway=service and service=alley:

"In some medieval European settlements alleys may be the very narrow
streets which run in-between buildings, providing public through-access.
" ( http://wiki.openstreetmap.org/wiki/Tag:service%3Dalley )

These kinds of streets are not only common in old town centers in Europe
but can be found in any place in the world that hadn't been built with
cars in mind, in shanty towns and also in modern (non-shanty) towns -
especially in Asia.

Now, the alley tag mentioned is problematic because there is no clear
definition what may still count as an alley and what should be a
residential road already.

Actually I raised the same issue 3 years ago in the forum
https://forum.openstreetmap.org/viewtopic.php?id=21942 (with links to
example imagery).
The outcome, more or less was:
* do not use living_street for non-living-streets
* use path/footway for anything that does not fit a car anymore (i.e.
only a motorcycle/rickshaw)
* use highway=service + service=alley for residential alleys that barely
fit a car if convenient
* otherwise residential for everything else, use width/lanes to give a
hint how wide it is

(Not saying that I am absolutely content about it, it is still ambiguous)

The existence of these discussions about how to tag really small
residential roads popping up and the living_street tagging being popular
where there is no such (legal) thing as a living street again and again
is a sign that there is an unalleviated uncertainty and thus room for
conflict and disagreement about this, since it is not clearly defined.

Now, talking about this is good. But can we solve and clear this up here
in the interest of all mappers and correct the ambiguities in the wiki
definition once and for all?

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

[OSM-talk] StreetComplete Betatest (osmagent)

[Tobias Zwick]

Hey people

I created a first early version of StreetComplete (renamed from
osmagent), the Android App for surveyors I recently mailed about. If
anyone is interested to test it in the field, I would be happy for any
more feedback.
Don't expect too much, I first needed to get the basics working.

I created a forum thread for this again to not generate too much noise
here on this mailing list, as I am hoping to get much feedback (and bug
reports) :-)
https://forum.openstreetmap.org/viewtopic.php?pid=620441

The APK is here:
http://www.westnordost.de/streetcomplete/streetcomplete-0.1-unsigned.apk

Github is here (for bug reports etc):
https://github.com/westnordost/StreetComplete

Cheers
Tobias

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

[OSM-talk] Android survey app: osmagent

[Tobias Zwick]

of shaders to the map. Other than
that the map may look cool, it also means that it
would be possible to directly display the answer
the user gave on the map (i.e. the building height)

State of development
---
See here: https://github.com/westnordost/osmagent

Of the quests, currently implemented are only "road name", "shop opening
hours" and "contribute to note" as proof-of-concepts, I am still working
on the base system. Adding more quests will be an easy
exercise.
What's missing on the base system is the logic when the system should
download quests and upload the changes the user made. Also, since the
app is making direct changes to the DB in the name of the user, I want
to write more tests before I make it available.
But that's it, pretty much, what is missing for a first release.

In the forum thread, I linked a few screenshots so that you can get an
impression of the app:
https://forum.openstreetmap.org/viewtopic.php?pid=616369#p616369

Cheers
  Tobias Zwick (westnordost)

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