Mappers do not think about maintenance.

I just added one more thing to StreetComplete: it will ask whether old defibrillators are still present. Added in https://github.com/streetcomplete/StreetComplete/commit/f822241d5827beffa8f5cce717a64ce079298076

These annoyances stack up and at some point you as a data consumer start asking yourself “is it even worth trying to use OSM data?”.

I agree, and I am not claiming that it is always a bad idea. Just that distorting situation and claiming that it is the largest problem ever is simply incorrect.

And it is necessary to be aware that existing data consumers processing OSM data are not happy about retaggings which force them to start supporting new tags, just to hadle things which were covered by deprecated tagging.

Even if such changes would be overall justified - current data users are going to be the grumpiest as they have all negatives without positives.

In general I expect that if someone organized mapping campaign, let other people that something specific was worth mapping - then it is the reason for more objects being mapped.

Not retagging itself. And that the same growth would be achieved without retagging.

world-scale replacement

I am not convinced that the growth rate increased as result of retagging.

I rather expect that both retagging and higher growth rate was caused by some other effect.

Not to mention replacement of waterway=riverbank with natural=water + water=river during last 2 years with already more water=river than legacy riverbanks.

And to compare actual growth rate it is necessary to take into account both tagging methods - both before and after.

how can one state (…) [that] letting duplicate tagging scheme without convergence perspective isn’t critical?

I just did, based on my experience and comments that I have heard from other users of OSM data.

how can one state tagging replacement is globally bad

I have not stated this, and in fact I participated and initiated some of them.

That could be good as well to provide figures like I do to discuss such points. Please provide facts.

fact: at least some data users and people writing software using OSM data do not consider duplicated/deprecated tagging schemes in use as a critical problem. In this specific post presented sample size is small (n=1: me), but I heard similar comments from other people. Maybe I should track down comments that I remember or try to survey such people.

If anyone else wishes: feel free to steal that idea, I have more plans and ideas than I can do in my lifetime and proper overview from other people using or trying to use OSM data may be interesting.

I am curious what would be listed as top issues, though I am betting that “duplicate tagging schemes” would be:

• not listed the biggest problem (96% confidence, and only because there is risk of very badly done poll)
• outside top 5 biggest problem (90% confidence)
• outside top 10 biggest problems (75% confidence)
• within top 20 biggest problems (80% confidence)

Am I publishing into Public Domain? Creative commons license? Do I lose my rights on the photo?

no, there is no agreement/terms of use or anything that would indicate this, photos remain fully copyrighted by the author (and possibly others in case of a derivative works not covered by freedom of panorama)

What will westnordost do with the photos in the future? delete them after a while, sell them? What if the photo is delete it before the note is solve?

Photos are deleted after note is solved. In case of server running out of space oldest ones will become deleted.

As copyright is not transferred, westnordost is unable to sell this images

There are many legal questions in this field, and the main page just shows a blog from someone that went to a beach and other places

As an explanation: that is because photos are hosted on server operated by author of StreetComplete (to keep it menageable and without runaway budget)

If you think that StreetComplete should be modified to explain situation (or hosting site should be somehow modified) feel free to open an issue at https://github.com/streetcomplete/StreetComplete/issues

Typical of these proposals is not only to they bring -zero- additional value (after all the objects were already being mapped)

I would not go as far to say that things like fixing typo in tag brings zero value, but often overall benefit is dubious at best or clearly negative.

(I count discussions related to deprecation, effort to create proposal/vote, decide on applying or not the deprecation in editors as a cost, annoyance to data consumers is also cost etc etc)

To use a recent tag-churning example, parcel drop off/pick up machines

Yeah, this one was better to be kept as is.

It should be noted that the proposal process does not include terms for handling “deprecation”

It actually mentions deprecation a bit. Though mostly to make clear that deprecation vote is weaker than some proposal process participants expect:

Do not expect an approved proposal to be automatically rendered or added to presets; this is at the discretion of the stylesheet maintainers and code authors. Also, never use a vote result as a permission for large-scale re-tagging of existing objects. See automated Edits code of conduct for more about this topic.

Do not remove entries from Map Features even if your new feature that has been voted on is intended to replace them. It is not considered good style to remove things from Map Features while they are still in use. You can remove things from Map Features if they are not in a significant use. See also Deprecated features.

Además, cuando se están resolviendo dichas notas desde JOSM, la URL de las fotos tiene un carácter llamado Zero Width Character (https://unicode-table.com/en/200B/) que no es visible pero existe. Este carácter cuando se pega en la URL de un explorador se convierte a su valor hexadecimal y por lo tanto no se puede acceder a la foto.

Zero width character is a JOSM bug, see https://josm.openstreetmap.de/ticket/21597

StreetComplete is not a problem here.

Why licensing would be a problem? You can use fully copyrighted photos of a place to map, problems start when you copy from maps/databases.

(I am not a lawyer, but I am one of more of unusually strict people as far as copyright goes and I do not get what is supposed to be a problem)

sorry for English, and sorry for answering autotranslated version. Sorry if I misunderstood something.

I am answering as I am one of people developing SC and wanted to check is there something improvable on SC side.

cartographic map

I want to note that it is seems to be a tautology or at least unusual term.

Note that https://www.google.com/search?q=%22cartographic+map%22 finds mostly blog spam and discussion concerning computer game mod.

Making any map, including low quality ones is also part of cartography.

stabilise the base dataset (remove pointless and sometimes harmful schema changes

While substation sub_station attracted negative comments ( https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-29238913 ) and there are some issues about similar changes…

This is not actually a serious problem and actual effort wasted on that was pretty minimal.

Therefore cartography is entirely irrelevant to the project.

Given that one of primary uses of OSM data is making maps and nearly every OSM editor presents data for editing as a map… Design of map style in editor is also a cartography.

total lack of any QA

You keep repeating clearly false claims, while it was initially entertaining to respond I guess I should stop wasting time.

if it was to replace work done on the desktop

It is definitely not intended or planned future.

It is intended to be used especially for tasks requiring survey on the ground and updating many objects, likely it will never be great in mapping buildings, landuse, road geometries, waterway geometries.

It is also intended to give people ability to contribute with low effort.

It is intended to supplement JOSM, not to replace it.

Simply changing colours is not cartography.

Cartography is in general defined as “study and practice of making and using maps” or similar.

Making any maps at all, even really bad ones and in outrageous projections as web mercator is still cartography.

In the same way as writing useless program in a terrible way is still programming.

I am not going to spend hours on making thorough overview, given that single exaple of anything at all is a sufficent counterexample to this clearly false claim.

https://github.com/ZeLonewolf/openstreetmap-americana for example

I am not trying to convince you that it is cartography that you like or appreciate - but it is cartography nonetheless.

Claims less aggressive than “OSM is doing nothing on any front” may be harder to disprove.

Can you give examples of what is OSM doing on cartography front?

I’ve mentioned some of a number of cartography commissions (“directions” if you wish) which ICA is busy with, OSM is doing nothing on any front.

“Commission on Maps and the Internet”

(…) semantic issues in cartography and spatial data, participatory mapping and co-creation approach in cartography, new education methods related to the Internet, Big data, Linked Open Data or Internet of Things (…) new Internet mapping technologies, multinational and multicultural perspectives of Internet maps or Service-Oriented Mapping. (…) Support education activities related to maps on the Internet. (…) Organise (or co-organise) ICC sessions, workshops, hackathons, mapathons and international conferences to meet, interact and exchange knowledge, experience and ideas (in several cases, the events can be transformed into the virtual space to arrange a higher number of participants). (…)

Maybe OSM is not doing anything that you like on this topics, or people doing it are without proper credentials that you want, or you disregard their Carto/GIS/IT experience.

But “OSM is doing nothing on any front” is clearly and blatantly false.

Some examples of “legitimate” bloat tags. I understand that these are subjective. ) “opening_hours:signed=” appears to have been created by you as a placeholder key and it only benefits Street Complete. Flags on data that are used for quality of life improvements in the app should be solved in the app.

I admit that I started using it when I was mapping with SC and from start planned to use it in SC, but I wanted something like this earlier - to skip places not bothering with signing opening hours.

In my defense I can say that I consulted it with tagging mailing list - if there would be some consensus that it is a bad idea I would drop that idea.

Though I agree that it is subjective, close/borderline case and I can see why someone may be against this tag.

“crossing:island=no” is a value that can assumed to be “no” instead of needing to apply it to every known crossing in OSM. I believe, I saw a post which says SC limits what types of streets it will place this tag on. I’m sure that helps but why is it placed at all? 353,000 (70%) unnecessary tags. The same thing applies to other tags like “tactile_paving=no”. Again, I don’t care enough to fight over it.

I guess that sidewalk=no, cycleway:both=no, noname=yes, lit=no also belong here.

Here I guess that it depends on whether and when someone considers as acceptable to record “this place was surveyed to check for XYZ and it was not found”.

Either way thanks for sharing this position! I am not rushing to delete all quests that use this tagging, but it is useful to know what is making people unhappy.

“all affected data was repaired” I believe you folks made a solid attempt. Regardless, I have fixed and continue to fix some of these SC errors. As you know, SC v28.0 had an error with crossing/kerb tags. If it was a larger problem I would not know. I only noticed that it would remove all tags on barrier=kerb / tactile_paving=* nodes.

Hmm. Can you link some affected objects? It is not on the list of banned versions ( https://westnordost.de/streetcomplete/banned_versions.txt ) so if there was data damage it could be missed. See

I just noticed this error from SC v38.2. Changeset 115319560 (SC v38.1) added tactile_paving=yes to crossing node on 2021-Dec-23 [Node: 4291702901]. Nodes at each end of the footway=crossing have had tactile_paving=yes since 2017-Feb-26 [Way: 436979377] [Node: 4694343209] [Node: 4707439042]. Therefore, we now have double tagging and the crossing node should not have had the tactile_paving=* tag added. Not a huge deal but it can be frustrating.

Yes, this is kind of duplication - but it is more of a tagging schema issue than SC-specific issue (at least in my opinion).

I have come across other issues from time to time but the crossing/kerb tags being deleted was the worst one that affected me. I would include more variety in errors but I can’t recall which nodes or ways had the other issues. Normally, the issues are minor so either I fix it or I ignore it and move on.

If you see it again, and it is not working as intended - please make report at https://github.com/streetcomplete/StreetComplete/issues/new/choose

I do not remember this being reported.

And crossing ques has no “does not exist” option that would delete it, only leaving notes. As it is too complex to handle by SC.

No idea what is going on, if anyone spots this happening - please report it as a bug.

(maybe it is not a bug, but it sounds like a bug to me)

I just get frustrated with these issues from time to time but these are small problems. I love the idea of StreetComplete. I enjoy the look and feel of StreetComplete. I’m ok with the function of StreetComplete. I hate how well-meaning fans of the app keep pushing it to do more and to do everything. StreetComplete filled a great need. A very easy to use program that is error proof in adding tags. That is my opinion.

Mateusz Konieczny, I want to say, I appreciate how you handle criticism.

Thanks, this is nice to hear! Hopefully I have not changed your opinion by this answers.

@G1asshouse Thanks for answering! I will see what can be improved.

I will answer to the entire comment, but I will do it bit by bit because it is a bit overwhelming.

“complicated situations” surface=* - Long ways that cross different surfaces (example: asphalt → paving stones → asphalt). It will get tagged with “asphalt” leaving the middle segment tagged wrong. I know that SC can do some edits like splitting a way.

Do you have any idea is it caused by mapper not caring about data quality? Or by someone unaware that splitting is even available?

Or maybe it was happening before splitting tool become available?

Either of this things would require a different action: either making split more prominent in the interface, or educate people that it exists, or maybe introduce even a special message shown to people who made many edits without using split tool. Links to changesets would be welcome - I can try contacting this mappers and asking them what went wrong.

roof:shape=* on non-flat roofs. Roof shapes are often complicated and tagging a simple building outline results in a simple roof shape. Often, what should happen is a complicated building needs to be redrawn with building:part=* and each building:part=* gets the appropriate roof:shape=* tag. I’m sure there are plenty of better examples but my statement is more about the general idea that

roof:shape was recently disabled by default (partially for that reason, partially due to poor effort/effect ratio).

Maybe limiting to people interested in roof mapping was enough? Let me know if that step was insufficient.

StreetComplete has expanded to include tags that are more complicated to add than they appear to be at first.

I would rather say that everything is more complicated than expected. In other words reality is unexpectedly complex.

This wouldn’t even need to display a map and if it does a single OSM tile would suffice.

This would end in creating duplicates and would be therefore a poor idea.

Maybe they’re open to adding another quest type for outdated POIs and other data.

“Is this still here?” quests exists for some nodes ( osm.wiki/StreetComplete/Quests )

For areas it gets trickier and require a full scale editor to handle things.

Shops that are discovered to be gone during opening hours quest can be retagged to another POI or marked as vacant property.

Notes can be always left for all quests, typically used when object being asked about is gone.

You’ve often mentions how “Vespucci can do that!”. Perhaps there is issues in informing (potential) users about these features.

I think that problem is that many users are scared away by overly complex interface. I like Vespucci, I edit with Vespucci a lot, I tried to convince people to use Vespucci but all that tried basically run away.

While I had some success with iD, StreetComplete and JOSM.

Initial experience really scares away people and there are other parts where I would consider removing functionality to keep interface more usable. For example “keep changeset open” checkbox.

https://github.com/MarcusWolschon/osmeditor4android/issues/899#issuecomment-886530450

Initial startup after the first install has very confusing screen with space for manual coordinate input, ability to search for location by name (with dropdown for Photon/Nominatim).

Why not just zoom to current location?

Or have a big button “edit in my current location” that would zoom in and download data in one click.

What is the difference between “load” and “go to map”?

Why selecting “current location” is not doing anything (I need to also click one of the buttons).

Why “current location” and “last known location” even show lat/lon?

Why it would be clear for a new user?

I would consider seriously simplifying this form, I am not surprised if many people would fail to ever download data after installing.

So my expectation that we will end up just with iD and maybe one nav app with some add on editing in the longer term.

At least JOSM, level0, StreetComplete serve different needs and would stay.

Even if iD would need to be actually usable on mobile. And it seems to be very far away from becoming a real replacement for Vespucci and not becoming closer to that. And it seems fundamentally lacking offline support at all, which is a critical Vespucci feature.

While with - very significant investment - iD can be made better than Vespucci in all relevant aspects and therefore replace it, and on timescale of decades/centuries it will happen or both will be replaced by a new editor. If OSM will exist for so long time and it is a very significant if.

But I cannot really imagine it being still relatively newbie friendly (while trapping them with some leaky abstractions) and having JOSM features and performance.

And merging JOSM, iD, level0, StreetComplete into one editor seems not really feasible.

not asking for a complicated editor it could be a stripped down iD or a gloriffied script it just needs to find and make it easy to add preset POIs

making it properly requires significant effort

just hiding some features from iD is not enough