Re: [OSM-talk] Mechanical Edit: Merge of DB Netz AG and DB Station&Service AG to DB InfraGO AG

[Michael Reichert]

Hi Mateusz,

Am 08.12.23 um 11:00 schrieb Mateusz Konieczny via talk:

Why remove operator:wikipedia=* rather than fixing them?


I would have to change operator:wikipedia=* to point to the new article 
(https://de.wikipedia.org/wiki/DB_InfraGO). However, the tag is a 
duplication if operator:wikidata=* is set. If operator:wikidata=* was 
set, I will update it. If operator:wikidata=* was missing but 
operator:wikipedia=* was set, I will set

operator:wikipedia=de:DB InfraGO.

Best regards

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Mechanical Edit: Merge of DB Netz AG and DB Station&Service AG to DB InfraGO AG

[Michael Reichert]

Hi,

as of 1 January 2024, DB Netz AG and DB Station&Service AG will merge 
and renamed to DB InfraGO AG. This requires an update to lots of 
operator=* tags including operator:wikidata=*, and some owner=* tags. 
The mechanical edit will also remove existing operator:wikipedia=* from 
the modified objects.


The mechanical edit affects mainly Germany, but some infrastructure is 
located in Switzerland, Belgium and Czech Republic. That's why I post at 
this mailing list at all.


You can find the documentation at
https://wiki.openstreetmap.org/wiki/Automated_Edits/Nakaner-repair/DB_InfraGO_AG

Best regards

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Bad coastline edits in Sweden

[Michael Reichert]

Hi Andre,

Am 21/11/2020 um 10.54 schrieb Andre Hinrichs via talk:
> Hi list! I'm doing a lot coastline fixings all over the world. Normally
> only with few pain. But since a few weeks the user Aki_Suokas is doing
> very bad coastline edits in the area of Sweden. I've written him several
> time via changeset discussion but no reaction.

Not reacting on changeset comments (or not following the advice given in
the comments) but continuing to edit, is a usual reason for 0-hour block
by Data Working Group. Please email d...@osmfoundation.org and explain
the issue with links to changesets/objects.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi Joseph,

Am 18/07/2020 um 21.51 schrieb Joseph Eisenberg:
> Do you have evidence that most of the surface tags added by this user are
> unreliable?

Review results by westnordost
(https://forum.openstreetmap.org/viewtopic.php?pid=795002#p795002,
translated with DeepL):
> Here are some bad examples from Hamburg:
> * https://www.openstreetmap.org/way/206273110 is paved according to my aerial 
> photo. grade5?
> * https://www.openstreetmap.org/way/771306038 is railway ballast.
> * https://www.openstreetmap.org/way/682991344 looks like grade2 to me.
> * https://www.openstreetmap.org/way/615485384 looks more like grade3.
> * https://www.openstreetmap.org/way/191452732 is grade one or grade two.
> 
> But other changes are ok.
>
> But since so much is obviously totally wrong, I'm in favour of a
> revert.

Review results by EinKonstanzer
(https://forum.openstreetmap.org/viewtopic.php?pid=795025#p795025,
translated with DeepL):
> Please do not reverse on principle and also no dogmatism of the kind.
> 
> I have picked out random edits from the last 2 months and looked closely at 
> them.
> - He has put in a "tracktype".
> - No position correction, and no other improvements.
> - And he uses the ID editor...
> 
> Norway:
> https://www.openstreetmap.org/way/608668696 - grade3 could be there
> 
> Czech Republic:
> https://www.openstreetmap.org/way/308938930 - with Bing there is nothing to 
> see, grade5 is no added value
> https://www.openstreetmap.org/way/758054333 - with Bing, Esri is absolutely 
> not to be recognized, with Maxar can guess the lower part of the way
> 
> Poland:
> https://www.openstreetmap.org/way/178772018 - Aerial photos are good, but in 
> this case it is clairvoyance to the ground is probably sand.
> 
> Germany:
> https://www.openstreetmap.org/way/207182973 - a track nearby that looks 
> almost identical has a different tracktype. Why?
> https://www.openstreetmap.org/way/102969056 - a track in the forest. Even 
> with the better Esri pictures there is no track to see!
> https://www.openstreetmap.org/way/370198123 - split the track, because 
> sections are definitely different. For one part grade4 might be OK. For the 
> other, grade5 at most.
> https://www.openstreetmap.org/way/134726358 - a big field. In the current 
> aerial photos (Bing, Esri, Maxar) there is no track at all!
> 
> Denmark:
> https://www.openstreetmap.org/way/332757646 - the edge of a big meadow, where 
> a tractor once drove along. No current track, and certainly not grade4
> https://www.openstreetmap.org/way/290360323 - On parts of the pictures a 
> track is partially recognizable, on others there is no/hardly any way. grade5 
> is no added value there
> https://www.openstreetmap.org/way/826303189 - A large meadow where the 
> tractor has cleared a path. If then grade5 but not grade4
> 
> Turkey:
> https://www.openstreetmap.org/way/203478714 - another track next door that 
> looks like the same or bigger parts is grade3, this grade4. But they could 
> all be grade2 as well...
> https://www.openstreetmap.org/way/294278418 - grade4. In my opinion rather 
> grade2 or grade3. Position correction urgently needed. Well...
> https://www.openstreetmap.org/way/203478238 - See previous
> 
> Conclusion: Revert and he should please stop that.

Mind that Modest7 used Bing imagery despite better imagery is available
in parts of Germany but not used by iD by default.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi,

Am 18/07/2020 um 21.19 schrieb Mateusz Konieczny via talk:
> Are you sure that just satellite imagery was used? I suspect that also
> aerial imagery was used in edits.

In Hamburg, Germany, where aerial imagery of the city is available, Bing
was used.

>> I think that the description "all objects modified by Modest7 since 1
>> January 2020" is sufficient.
>>
> I thought that revert was supposed to cover tracktype edits only?

That was my plan initially. However, after scrolling back his edit
history, I found edits adding surface in the US. There is some overlap
in the meaning of surface and tracktype, therefore I think that it makes
more sense revert changes to both tracktype and surface, not tracktype
only. The revert is limited to these two tags because some changes by
Modest7 are indeed helpful, e.g. adding intersection nodes to
intersecting roads.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi Mateusz,

Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
> Can you link affected data in Poland? 
> 
> In Poland you actually can reliably estimate real tracktype based solely
> on high quality aerial images (not satellite imagery that is unlikely to be 
> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
> Cień dataset.
> 
> Note that your planned automatic revert likely counts as automatic 
> edits and needs to fullfill
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> requirements, including support from other editors.

I do not think that my revert is an automated edit as intended by the
Automated Edits Code of Conduct. I am reaching out to the community in
advance because different people might have a different opinion on how
reliable tracktype=* needs to be and how reliable surveying from
satellite imagery is.

I think that the description "all objects modified by Modest7 since 1
January 2020" is sufficient. You can use OSMcha, can't you? Or would you
like to have a large .osc files of his changes?

Currently, the revert is disputed. That's not a condition I would like
to have for a mass edit. If people in favour of a revert will not voice
their opinion in this discussion, it is very likely that I will not do
the revert on international level.

The Polish community is free to object as it is their data (quality),
not mine. I asked the German community today because I suspect that
Germans are quite sensible when it comes to one of our key assets of OSM
in Germany: surveyed highway=track. If people on the German forum agree
with a revert, the revert will be limited to Germany. If other local
communities ask me to perform the revert in their country, I will do it
there.
https://forum.openstreetmap.org/viewtopic.php?id=70056

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi Mateusz,

Am 18/07/2020 um 19.29 schrieb Mateusz Konieczny:
> Can you link affected data in Poland? 
> 
> In Poland you actually can reliably estimate real tracktype based solely
> on high quality aerial images (not satellite imagery that is unlikely to be 
> sufficient), typically Geoportal 2 aerial and LIDAR data available in ISOK 
> Cień dataset.

I don't have a list of the affected OSM objects at hand but you can
filter his changesets in Poland using OSMCha. Note that I do not
guarantee that Poland is affected at all. It might be that his changes
in Poland are limited to other kinds of contributions like adding nodes
to intersecting roads.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Planned revert of added surface and tracktype tags without local knowledge in various countries

[Michael Reichert]

Hi,

while reviewing changes in my local area, I discovered that user Modest7
has been adding tracktype=* tags to lots of highway=track at various
locations. I asked him what sources he used apart from the satellite
imagery mentioned in the imagery_used=* tag of his changesets. See
https://www.openstreetmap.org/changeset/87236896 for a discussion with him.

I do not believe that one can add reliable tracktype=* information from
satellite imagery without having some ground truth knowledge in order to
know how to interpret the imagery in that region. Adding estimated
tracktype=* does not help OSM on the long term. People how rely on the
information (e.g. some wanting to drive or cycle on that track) are
disappointed about this low-quality OSM data. Mappers who decide where
to map assume these roads to be mapped properly. IMHO, adding
fixme=resurvey tracktype will not improve it. Data consumers usually do
not use tags like fixme=* In the case of imports (another type of mass
editing), we say that an import must not add fixme=* to cover
shortcomings of the data to be imported because they usually do not get
fixed in a reasonable time. Therefore, I plan to revert these changes.

Modest7 does not seem to realise that estimating tracktype from
satellite imagery is not doing a service to OSM. I am currently
preparing a revert of all additions of surface=* and tracktype=* by him
he uploaded since 1 January 2020 [1]. The revert will only edit tags,
geometry will stay unchanged. I revert changes on surface as well
because that's not very different to tracktype except that it applies to
other types of roads as well.

The countries which will be affected are:
Germany
Denmark
Turkey
United States
Poland
Ukraine
Morocco
Czech Republic
Lithuania
Sweden
Norway
eSwatini

A changeset discussion with him can be found at
https://www.openstreetmap.org/changeset/87236896

Best regards

Michael


[1] This date is not fixed yet.



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Michael Reichert]

Hi,

Am 19/06/2020 um 16.06 schrieb Simon Poole:
> In any case doing that from scratch would be a real pain. I believe the
> OSC stack is now actually all OSS which would be a far better starting
> point -if- sustainable funding could be built around the whole thing.

I looked at the GitHub repositories of OpenStreetCam about two weeks ago
because I remembered that someone having claimed a couple of years ago
OSC to be open source with some minor exceptions.

https://github.com/openstreetcam

I found the source code of the Android and iOS app and the website but
no code for a backend on a server. A deeper look into the repository of
the Android app points out that the publice source code lags behind the
release in Google Play and some of its dependencies make it unsuitable
for F-Droid [1].
https://github.com/openstreetcam/android/issues/153
https://github.com/openstreetcam/android/issues/113
https://github.com/openstreetcam/android/issues/149

Best regards

Michael


[1] I consider the people running F-Droid to be as picky w.r.t. building
things from source as people at Debian are. 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Michael Reichert]

Hi Mario,

Am 08/03/2020 um 16.00 schrieb Mario Frasca:
> well, it does look slightly invasive … I had imagined something like a
> transparent text on top of the requested tile.  doing it the way you are
> doing it, you are removing part of the underlying information.

A transparent overlay requires calling Imagemagick or a similar tool for
each tile and to cache the results. It makes the setup more complicated
and requires more processing power. Should we spend even more volunteer
time and donations on abusers? No.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Creation of "Data Items" by bot for undocumented tags

[Michael Reichert]

Hi,

Am 18.02.20 um 18:46 schrieb Frederik Ramm:
> Agree, and I would also request that *any* automated change to the Wiki
> be discussed before it is implemented. The use of bots puts too much
> power in the hands of those who write them, and this must be balanced by
> a requirement to involve the non-bot-writing part of the community
> before launch.

I think that the Automated Edits Code of Conduct should be extended to
edits on the wiki and proposed edits covered by it discussed on this
mailing list if their scope is global or spans multiple countries.

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Michael Reichert]

Hi,

Am 04/02/2020 um 15.25 schrieb Frederik Ramm:
> Hm, the wording is a bit unfortunate really. Of course this "internal
> use only" applies to the personal data in the file which according to
> (the LWG's interpretation of) the GDPR is ok to use for OSM's own
> purposes but not for blasting it out into the world. The
> non-personal-data history is free for everyone to use, and Geofabrik
> *could* actually make two different history files available, one with
> and one without user data, it's just that these files are a niche
> interest anyway so we thought one version is sufficient.
> 
> This means that if you derive anything like an animated map from the
> data, that's totally fine; only if you were to publish something that
> involves user data should you think twice about your data protection
> regulations.

You can strip the history files from osm-internal.download.geofabrik.de
using the following Osmium command to get OSM data with fewer legal
risks in terms of personal data:

osmium cat --output-format pbf,metadata=version+timestamp \
  -o output.osh.pbf input.osh.pbf

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should a deleted user's chainset list be removed?

[Michael Reichert]

Hi,


Am 11. Oktober 2019 11:52:17 MESZ schrieb Martin Koppenhoefer 
:
> When you know the userid you can grep their changes from a history
> file
> (e.g. with osmium tool and the opl format).
> Provided you don't have a history file around, it is a serious effort
> though, due to the file size...

Changeset IDs can be retrieved from the changeset dump (an XML file, very slow 
to parse).

If the activities of the user were limited to a specific region, you can 
download an extract of the full history planet dump with all user data from 
https://osm-internal.download.geofabrik.de/ The full history planet dump 
extracts are updated weekly.

Best regards

Michael

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

[OSM-talk] State of the Map 2019 being sold out soon

[Michael Reichert]

Hi,

State of the Map 2019 in Heidelberg (21–23 September) is on the straight
way to success – we expect to be sold out in the next hours. At the time
of this writing, 535 of 570 tickets are sold. Please order a ticket as
soon as possible if you want to visit SotM.

Most sessions of SotM will be recorded on video. The livestream and
recordings will be made available at https://media.ccc.de/ See the
programme at https://2019.stateofthemap.org/program/ and
https://2019.stateofthemap.org/academic_programme/ which sessions will
be recorded.

Best regards

Michael Reichert
SotM Working Group



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overpass API - Fetching countries, their capitals, and their borders

[Michael Reichert]

Hi,

Am 13/08/2019 um 23.41 schrieb Léo El Amri via talk:
> I'm trying to fetch countries, their borders, and their capitals through
> Overpass API, but the server never replies to me (With a timeout:3600
> setting, the server reply with a 502 error after a while).
> I'm only a beginner with this API, so maybe my request is not efficient:
> 
> (
>   node[place=city];
>   node[place=town];
> )->.a;
> rel[boundary=administrative][admin_level=2]->.b;
> (
>   node[place=country];
>   node.a[capital=yes];
>   way[boundary=administrative][admin_level=2];
>   .b;
>   .b >;
> )->.o;
> .o out body;
> 
> What am I doing wrong ? (Should I use another tool for this purpose ?)

That's a lot of data.

Download the planet dump in .osm.pbf format from
planet.openstreetmap.org or a regional extract from
download.geofabrik.de and use Osmium's tags-filter command.

Depending on your goal, it might be sensible do to a rough filtering
with Osmium and then import the OSM file into a PostgreSQL database
using Osm2pgsql.

Best regards

Michael




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] State of the Map 2019: early bird until 21 July, poster submission

[Michael Reichert]

Hi,

this year the international OpenStreetMap conference called State of the
Map, takes place in Heidelberg, Germany. The programme has been
published a few weeks ago, (almost) all descriptions of the talks were
published on Wednesday.
https://2019.stateofthemap.org/program/

SotM is the chance to get in touch with many other people from the OSM
community. In addition to the talks and workshops, there will be rooms
for self-organised sessions where people spontaneously discuss topics
they care about. Some people think that this is the more important part
of SotM than the talks. :-)

Early bird tickets are available until 21 July:
Community EUR 75
Business EUR 180

https://join.osmfoundation.org/?page=CiviCRM&q=civicrm%2Fevent%2Finfo&reset=1&id=13

Tickets include admission to the social event (likely on Saturday) and
the poster exhibition (likely on Sunday).

Given the number of tickets sold already, I (as one of the organisers)
would not be surprised if SotM will be sold out this year. Don't buy
your ticket too late.

BTW, you can submit posters until 18 August for the poster exhibition.
Attendance at the conference is not required for it.
https://2019.stateofthemap.org/calls/posters/

Best regards

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Documenting controversial iD decisions

[Michael Reichert]

Hi,

I started documenting controversial decisions by the maintainers of iD
at https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

Currently, only the highway=footway and the nonsquare=yes issue are
mentioned.

Please feel free to add other issues which have proofed controversial so
far. Don't forget to summarise the opinion of the maintainer as well to
aim at least some neutrality as far as it is possible for those involved
in the disputes. Please add links to relevant discussions as well.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Improving iD on osm.org (WAS: Remove validation rule asking to add highway=footway to railway/public_transport=platform)

[Michael Reichert]

Hi,

Am 28.05.19 um 10:32 schrieb Frederik Ramm:
> I think this would definitely be the healthiest and most common-sense
> approach for the community. Letting an unchecked third party forge ahead
> with iD was good in the beginning but now we need some checks and
> balances in place to ensure that what the OSMF brandishes as the
> "default editor" is actually reflecting community consensus.
> 
> It's totally ok if the developers don't want to be bothered with having
> to find out what the community consensus is(*) - this is hard enough
> even for the community itself.
> 
> Perhaps it is possible to have a forked iD that does not work by
> meticulously cherry-picking every new change that is added to iD
> (because that would be too much work), but instead - a bit like the
> mechanisms when building a Debian or Ubunutu package - we could have
> some patches that we routinely apply to iD before it goes live on our site.
> 
> We could use this contentious "tag upgrade" as a test balloon to
> establish the new workflow: iD releases new version -> patch team
> applies existing patches -> community review -> if necessary, new
> patches are made -> patch team releses -> OSMF website deploys.

I am not sure if pure patching (a hard fork) will work on the long term.
Adding a blocking step in the release process might work in the
beginning but after some time the members of the distribution team loose
interest. In difference to projects with a volunteer dominated group of
contributors as OSM Carto, the distribution team will not produce a lot.
In contrast, its task is filtering. This can be torpedoed by the
maintainers of the parent project by code changes requiring a tedious
and boring application of the patches and the user base will ask what
the benefit of the distribution team will be and why we need such a
group at all. I have been active in WeeklyOSM for almost five years now.
I have seen people joining and becoming inactive after some time. I have
observed myself becoming more or less involved (varies a bit over time).
It needs discipline and a large team to get an issue almost every week.

I am pretty sure that there is another way to enable distributors of iD
to build the iD they want. iD could offer a couple of switches in a
central source file to disable or enable certain, controversial or not
always necessary features. (This idea is inspired by build flags for C
programmes but different) This concept might still need the application
of patches to the central file but patching a single file which is
basically a list of variable assignments appears easy to me.

These build flags enable the maintainers to stay to their personal views
on disputed matters but enables local communities more easily to host
their local iD and therefore foresters diversity. If the maintainers add
another feature which is not accepted for www.openstreetmap.org, the
distribution team can still fall back on patching with all its consequences.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] mass iD validation arrives in NYC

[Michael Reichert]

Hi,

Am 28.05.19 um 20:28 schrieb Simon Poole:
> The times in the changeset do not reflect the length of the associated 
> editing session except if the changeset was opened on purpose at the 
> beginning which IMHO no editor does.

A better method to guess the length of the editing session is to look
when the previous changeset was uploaded. (It assumes that the human
editing OSM does not have to open editing sessions in parallel)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

[Michael Reichert]

Hi,

Am 11/05/2019 um 21.09 schrieb Simon Poole:
> Just a general remark on the technical issue that sparked of this
> discussion:  squaring buildings is not primarily about improving data
> quality. Non-square buildings are simply visually annoying when
> rendered, so much that I support squaring them "as a rule" too when it
> can reasonably be assumed that there are 90° angles in the actual
> building outline. But I'm not kidding myself that it improves "quality".
> If we wanted to define quality of building outlines in OSM we would
> probably be talking about deviations from the buildings footprint area,
> average deviations from the outline and so on, any of these could be
> very small even without squaring. Actually, squaring might impact them
> negatively, particularly when the outline is rough, but as said: square
> buildings are just so much easier on the eyes :-).

Are buildings with rectangular corners buildings mappers from developed
countries want to see on a map because they look more professional/tidy? ;-)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Michael Reichert]

Hi,

Am 10.05.19 um 00:00 schrieb Jmapb:
> This strikes me as a pretty bad idea. I map in NYC where we have lots,
> lots, lots of nearly-square buildings with official footprints imported
> from the city's open data initiative. When a mapper not familiar with
> the history here gets a message from iD (which, to many mappers, is
> indistinguishable from getting a message from OSM itself) encouraging
> them to square a building, they'll do it because it seems like the right
> thing to do. So the official, highly-accurate footprints are lost. And
> adjacent buildings with shared nodes are also distorted.

JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
  objects they did not touch.

- If users follow suggestions how to fix blindly (we cannot expect an
  unexperienced iD user to have the same knowledge as the average JOSM
  user), they are used as living bots running validation rules on
  randomly selected areas of the map. One might call this a hidden
  automated edit.

In difference, iD runs its validation rules on all loaded objects.
https://github.com/openstreetmap/iD/issues/6332#issuecomment-490494331

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Michael Reichert]

Hi Mikel,

Am 09.05.19 um 23:14 schrieb Mikel Maron:
> Absolutely. My understanding is this feature will greatly improve data 
> quality in OSM. I think it's fair to validate squareness of existing 
> buildings.

I did not say that I am against the validation rule itself. I agree that
the rule is a great step forward. However, the turn-validation-off tag
is not necessary because most buildings are edited only one time:

ways with building=* except building=no:  341403310
  thereof version == 1:   277493561 (81.3 %)
relations with building=* except building=no:630284
  thereof version == 1:  406731 (64.5 %)

Limited to objects edited after 2017-01-01T00:00:00Z:

ways with building=* except building=no:  151163160
  thereof version == 1:   125435755 (83.0 %)
relations with building=* except building=no:349731
  thereof version == 1:  184564 (52.8 %)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Michael Reichert]

Hi,

this could be seen as a tagging discussion but I think that it is a
discussion on governance and power. That's why this email goes to the
Talk mailing list.

Quincy Morgan, one of the maintainers of iD, invented a new tag called
nosquare=yes today which should be added to buildings which are not
square and should not be flagged by iD's validator. I (and later Paul
Norman) pointed out issues with the tag. I asked Quincy to discuss the
addition with the wider community beforehand.

https://github.com/openstreetmap/iD/issues/6332

Here are the issues I pointed out in the bugtracker. At the beginning he
planned to use square=no which he later changed to nosquare=yes but this
change does not make things better:
> Although noname=yes is common, it is not that common that it can serve as an 
> argument in favour of introducing unsquare=yes. In difference to noexit=yes, 
> unsquare=yes and noname=yes only serve as a workaround for quality assurance 
> tools. noexit=yes also conveys information for map users: There road ends 
> here.
> 
> Some people prefer to tag as complete as possible and add oneway=no, 
> cycleway=no, lit=no etc. to any way. However, such a practice is not base on 
> a broad consensus and if you dig deep enough in the history of user blocks in 
> OSM, you might find blocks set due to an excessive use of negative binary 
> tags.
> 
> I think that iD does not need this tag and should only validate buildings if 
> they have been added or modified in the current session. If doing so, they 
> will be reported once which does not bother that much.
> 
> Adding such a tag is not a simple change as it might seem to be and I ask you 
> to discuss it with the broader community on the Tagging mailing list.

What do you think? Should the next version of iD be deployed on
www.openstreetmap.org?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] An Archive namespace for the OSM wiki?

[Michael Reichert]

Hi,

there is currently a voting on a Deletion Policy [1] for the OSM wiki.
The policy was drafted because we had two incidents last year when
someone tried to delete a large number of old and orphaned tagging
proposals in draft state. He claimed that these pages might confuse
users looking for a tag.

He is not totally wrong with that. These pages can be confusing but
there are reasons why other users (including me) claim that most
proposals should be kept.

In addition to these proposals, there is a much larger number of
outdated wiki pages about mapping techniques and OSM-related software.
Some can be updated but some can't: Pages about Kosmos document a map
renderer whose binary cannot be downloaded any more. Pages about
unmaintained/historic software like Traveling Salesman [2] or Namefinder
[3] are another example.

Deleting these pages is deleting memory and history. Rewriting them in
past tense and deleting unimportant content is a lot of work and is on
the borderline to vandalism if the page could be updated. However, such
pages should be treated different to make readers aware that they hit
something old and outdate. That's why I think that there should be a
"Archive" namespace on the wiki where such pages can be moved.

An alternative to a namespace is a template being added to these pages
informing readers that the page exist for archival purposes only. That
was done with the wiki page about Namefinder. It has already been marked
as "This page describes a historic artifact in the history of
OpenStreetMap. It does not reflect the current situation, but instead
documents the historical concepts, issues, or ideas."

What do you think?

Best regards

Michael


[1] https://wiki.openstreetmap.org/wiki/OpenStreetMap:Deletion_policy
[2] https://wiki.openstreetmap.org/wiki/Traveling_salesman
[3] https://wiki.openstreetmap.org/wiki/Name_finder

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Bank of India (and other) Wikidata tags

[Michael Reichert]

Hi Andy,

Am 17/04/2019 um 17.53 schrieb Andy Mabbett:
> There are currently 956 objects in OSM with the tag "wikidata=Q1340361":
> 
>https://taginfo.openstreetmap.org/tags/wikidata=Q1340361
> 
> where:
> 
>https://www.wikidata.org/wiki/Q1340361
> 
> is the item for the State Bank of India.
> 
> The tag should almost certainly be:
> 
>operator:wikidata=Q1340361
> 
> or, less likely,
> 
>brand:wikidata=Q1340361
>franchise:wikidata=Q1340361
> 
> with the only exception perhaps being the bank's HQ.
> 
> Can anyone confirm what the correct tag should be, and can we use an
> automated process to correct them?
> 
> It's possible that the same issue applies to some of the other
> high--use tags listed at:
> 
>https://taginfo.openstreetmap.org/keys/wikidata#values

The following Overpass query (bbox filter not required) shows all
features with wikidata=Q1340361 which is the Wikidata ID of the Bank of
India.

(node[wikidata=Q1340361];way[wikidata=Q1340361];);out geom meta;

By looking at the result, the following observations can be made:

- nyuriks is the last modifier of most objects
- most objects are banks having wikipedia="en:State Bank of India"

wikipedia=* on shops of chains is considered wrong. Usually, the article
is about the chain, not the individual shop itself.

Opening the changesets which modified the objects in their last version
leads to mechanical edits setting wikidata=* tags by simply copying
taking the value wikipedia=* and looking up its Wikidata ID. This is
should not have happened for the following reasons:

- computer programmes are better at copying and enhancing a planet dump
  with Wikidata IDs would be the better
- adding Wikidata IDs pretends a quality these objects do not have
  because no manual review happended
- the meaning of the Wikipedia articles and its associated Wikidata
  entry do not overlap fully

The errors pointed out by you, Andy, proof that it is an automated edit.
The Automated Edits Code of Conduct applies but was ignored then. The
Automated Edits Code of Conduct exists to prevent such issues. I haven't
digged in detail through the archives of the Talk mailing list but I am
pretty sure to find emails which mentioned these issues. However, the
issues raised back then were ignored.

The Bank of India issue is not an isolated incidence. Looking deeper
into the series of nyurik's mechanical Wikidata edits unveils more
issues. Cleaning up banks in India might remove one of the most obvious
and annoying errors of the mechanical edit but it does not solve all the
other errors still present in OSM. Each of them affects a smaller number
objects, not hundreds but only tens per error. They won't appear on the
first pages of Taginfos's list of tag values. But they still sum up to a
significant amount and make the wikidata=* tag as it is unreliable.
That's why I think that going back a step in this case would be the only
sustainable solution.

Best regards

Michael



PS nyurik's edit isn't the only problem here. The iD editor adds
wikidata=* if wikipedia=* is added without checking that the link of the
Wikipedia entry to the Wikidata entry is right and if the meaning of the
Wikipedia article is wider. I called this an mechanical edit

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Michael Reichert]

Hi Bryce,

Am 22/02/2019 um 08.02 schrieb Bryce Jasmer:
> The wiki page is https://wiki.openstreetmap.org/wiki/Automated_Edits/b-jazz

I have seen that you started uploading. Could you please add a link to
that wiki page to the profile page of b-jazz-bot or create
https://wiki.openstreetmap.org/wiki/Automated_Edits/b-jazz-bot
as a redirect page to
https://wiki.openstreetmap.org/wiki/Automated_Edits/b-jazz
in order to comply with the Automated Edits Code of Conduct.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Michael Reichert]

Hi Bryce,

Am 22/02/2019 um 08.02 schrieb Bryce Jasmer:
> I have written a script that will search for OSM objects that have a
> website tag that explicitly states "http://..."; or implicitly uses http by
> leaving of the protocol specification. The script will then loop through
> all that it discovers and asks the http site if it will redirect me to the
> secure version of the website over the https protocol. If it does, I will
> update the database with the new value.

Do you have any safeguards against POIs which do not exist any more and
whose domains are owned by domain sellers now? They often have a very
basic website with a message like "This domain is for sale." and some
advertisement. I would not be surprised if they support HTTPS (and maybe
HTTPS only) these days. Update website=* and similar tags would not be a
benefit to OSM but simulate some kind of up-to-dateness.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Board decision on Crimea complaint

[Michael Reichert]

Dear board,

Am 10.12.18 um 18:14 schrieb Tom Hughes:
> On 10/12/2018 16:55, Martijn van Exel wrote:
> 
>> On November 17, the OSMF Board of Directors received a request to
>> review the Nov 14, 2018 Data Working Group decision regarding Crimea.
>>
>> The Board decided that this decision is to be reversed and the
>> previous situation, as laid out in the May 5, 2014 Data Working Group
>> minutes, is to further remain in effect.
>>
>> The board highly values the Data Working Group’s work and appreciates
>> the difficulty and complexity of the cases they are asked to review on
>> an ongoing basis.
>>
>> A more comprehensive statement will follow in the next weeks.
> 
> With respect that doesn't make much sense.
> 
> Either you have a rationale for the decision, in which case you should
> state it, or you don't and just want to placate a vocal community.
> 
> At the moment it sounds like you've decided what result you want and
> now you're going to desperately cast around for a way to rationalise
> that decision in the eventual statement.

+1

@Board
Did you consult the working group being involved in boundary disputes
(DWG and LWG) before you came to that decision?

How does your decision comply with the on-the-ground rule?

Could you please share the original complaint with redacted names or a
summary of it and its arguments?

How many board members agreed, how many disagreed?

Did any board member not participate in the voting due to a conflict of
interest? Did these members participate in the decision making?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Michael Reichert]

Hi,

Am 24/11/2018 um 15.09 schrieb Andy Townsend:
> I'm not actually aware of a situation where countries have said "this
> bit belongs equally to both of us" (I'd be interested to hear of any
> examples, actually), though there are plenty of places where they say "I
> think it belongs to me, and you think it belongs to you, but let's work
> together and manage it jointly".

The rivers Moselle, Sauer and Our form a large part of the border
between Germany and Luxembourg constitute a condominium. The rivers,
their islands and bridges belong to both countries. AFAIK, there is no
dispute between the two countries. Therefore, the boundary relations of
both countries overlap.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Amazon Logistics (WAS: Short ways added to substitute barriers)

[Michael Reichert]

Hi Jem,

Am 29.10.18 um 04:08 schrieb Jem:
> Re: https://www.openstreetmap.org/way/634085262 and several more like it in
> the area.
> 
> It seems that new, short ways have been introduced to replicate the purpose
> of the existing barrier nodes. i.e. to prevent routing for vehicular
> traffic. I believe it is incorrect and just adds complexity.
> 
> I plan to contact the user to discuss, but want to make sure I'm right. Can
> any experienced members please advise?

This is an edit of an employee or contractor of Amazon Logistics editing
OSM. They documented themselves on the OSM wiki a few days ago after one
email by myself and two by the DWG. (I had escalated the case to DWG
because they continued editing in Germany without a documentation)

https://wiki.openstreetmap.org/wiki/Amazon_Logistics

My comments about the wiki page:

I would like to see the driver feedback directly, not the edits only in
order   to be able to analyse the whether the editing errors come from
the staff or if the reports are a useful source at all.

It is unlikely that all the errors they fix have been reported by
drivers or are derived from GPS traces. I assume that they do some
automated QA checks, e.g. for routing islands. Its results should be
published. This might help themselves because they can get feedback
from the community to improve the rules the QA software applies. I am
happy to help putting the results into OSMI or an instance of Osmoscope
if they are able to give me a shape file, SpatiaLite database or
anything else OGR can read.

They should publish the training material in order that other companies
can learn how the training should be improved. Yes, that leaks business
secrets but the OSM community and their work is more important.

I have observed the following issues with their edits:

(1) They add very short ways to substitute barriers (e.g.
https://openstreetmap.org/changeset/63524103): This should not be done.

(2) They add access=no/private inside closed areas where all roads
leading to the facility are access=no/private. This looks good to me.

(3) They add or remove oneway=yes or change the direction of ways. It
seems to be good in most cases but proper judgement is only possible
with local knowledge. Are they aware of the frequent exemptions for
bicycles and public transport?

(4) They "fix" the same locations they had fixed in spring this year
before I reverted all their edits in Europe due to too many quality
issues. https://www.openstreetmap.org/changeset/58217008
I have not evaluated yet if their second attempt to fix these "errors"
really hits the root cause of the issues or if it hides the root causes
again. (Fixing without hitting the root cause means that they make their
QA software not showing any error any more)

(5) Sometimes their edits are good but in many cases they either lack
local knowledge (or experience with German roads?) or the experience
with the access tagging schema and many other ways how OSM works. For
example, one of them recently revived a razed:highway=* by adding
highway= in a construction in the centre of Karlsruhe [1].
Nearby landuse=construction polygons, a changed layout of the
intersection and razed:highway=* (highway=* missing) did not keep them
from editing the way and having unlimited trust in Mapillary imagery. I
wonder if they trained their staff properly w.r.t. the risks of
couchmapping.

(6) Editing access restrictions of streets based on the visibility of
cars on satellite imagery: This should not be done with satellite
imagery only. It is too likely that the edit harms more than it helps
because the individual cars are explicitly permitted to use the road or
the imagery shows drivers violating traffic rules (but we usually map
the signs).

This trouble is one of the reasons why OSM should have a strong code
of conduct for paid and organised editing activities protecting
craftmappers and their work and ensuring that companies respect the work
of volunteers.

Best regards

Michael




[1] The construction sites of our two new tunnels in Karlsruhe make the
road layout change every few days. Any aerial image and Mapillary
imagery is outdated.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)







signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikibase is now live

[Michael Reichert]

Hi Yuri,

Am 18.09.18 um 11:30 schrieb Yuri Astrakhan:
> as of today, OSM Wiki can store structured tag metadata similar to
> Wikidata.  In every possible language, cross-linked, with images,
> validation rules, or anything else the community decides to store there.
> See examples:
> 
> Key:bridge:movable:https://wiki.openstreetmap.org/wiki/Item:Q104
> Tag:bridge:movable=bascule:   https://wiki.openstreetmap.org/wiki/Item:Q888
> 
> I have imported most frequent Keys from the TagInfo, plus parsed wiki pages
> to try to get multilingual descriptions, images, etc.  Our next step is to
> add more descriptive properties, translations, validations(?), better
> images. The structured data is accessible via Lua (our new templating
> language), so at some point we may want to replace info cards and tables(?)
> with the automatically generated ones.
> 
> Help is needed: our wiki is large and multilingual. If you can help,
> especially if you can run a wiki bot to automate some data parsing and
> wikibase item creation, please reply. When editing, please do not change or
> translate the "label" field. Only use description field for the translation
> efforts, add statements, etc. If you need new properties, please write at
> https://wiki.openstreetmap.org/wiki/OpenStreetMap_talk:Wikibase

Have you considered the side effects of this change?

Currently, the search of the wiki is not really useful any more. If I
search for any page and type the correct page title, the autocompletion
only returns Wikidata based results but no page titles. IMHO, this is
more harmful than the absence of structured data on the wiki which could
be stored outside the wiki as well.

I suspect that the attempts for more structured metadata won't be really
accepted by the community (the editors of the wiki). I don't find
https://wiki.openstreetmap.org/wiki/OpenStreetMap:Wikibase really
helpful to understand what to do and how to do it. Is there any better
explanation on the wiki?

TBH, if I were an editor developer, I would neither take regular
expressions for validation rules nor all my presets from the wiki. The
wiki can be edited by everyone. There are a lot people whose hobby is to
edit the wiki to make it represent how they expect OSM and the usage of
tags to be [1].

Best regards

Michael


[1] I did that in some cases in the past, too.

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Taking a stand against EU directive "Copyright in the Digital Single Market" (upload filters etc.)

[Michael Reichert]

Dear board,

I have filed a pull request on Friday to add a banner to the
OpenStreetMap website like our SotM banners.
https://github.com/openstreetmap/openstreetmap-website/pull/1979

I have not received any response yet but I have been told that the OSMF
board discussed it and was not in favour of it. I agree that they do not
want to decide on it and prefer the board to decide. But I haven't heard
anything official from you yet. Does this mean that the OSM Foundation
will stay silent on this critical issue and let the bad things happen?

I am not proposing black map tiles for tile.openstreetmap.org (although
I myself am in favour of it because our message would be everywhere).
Instead, I propose a banner which does not harm website usage more than
a SotM banner. Users of our map tiles or adblockers don't notice it at all.

The time frame was short and most of our community (me too) have not
realized early enough the threat but this should not hinder us from
becoming active now!

I myself don't want the foundation to be active in politics all the
time. That's not written in the Mission Statement but it authorises or
forces (?) the foundation to act against lawmakers' decisions
threatening the project.

To cite the OSMF Mission Statement [1]:
> The OpenStreetMap Foundation is there to protect the OSM data to keep
> it Free and Open.

And the section "Scope of the OSMF Board" further says:
> The OSMF board and board members
> * […]
> * Takes active steps to safeguard project relevance, future and
>   success

What's the problem with becoming active in politics if the open
character of the project is in danger? It is neither something totally
unrelated to us nor one of the hundreds of boundary issues on this
planet. We are not facing a sudden end of the project but adding
mandatory filters or reviews might drive away many contributors (maybe
including myself). Implementing these filters will be a lot of work and
require resources (volunteers and money) we would like to use for more
productive topics. Isn't this issue important?

FYI, the German Wikipedia is voting until 10 September 2018 24:00 CEST
on a banner for all pages and a making the landing page black. There is
large majority in favour of the plan.
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Schwarze_Hauptseite_gegen_Upload-Filter_und_Leistungsschutzrecht#Umfrage

Best regards

Michael


PS An English translation of the German page explaining the problems of
upload filters (https://www.openstreetmap.de/uf/) is under work.


[1] https://wiki.osmfoundation.org/wiki/Mission_Statement

Am 06.09.2018 um 22:47 schrieb Michael Reichert:
> Hi,
> 
> on 12 September, the plenary of the European Parliament will vote on the
> new EU directive "Copyright in the Digital Single Market". The directive
> will introduce upload filters requiring internet platforms to scan
> contributions of their users for potential copyright violations
> automatically. The original proposal has passed the Committee on Legal
> Affairs on 20 June and failed in the plenary vote a few days later. If
> the plenary accepts the slightly modified proposal on 12 September, the
> trialogue negotiations between the European Parliament, the European
> Commission and the Council of the European Union will start. See also
> https://saveyourinternet.eu/ for more information in your language.
> 
> The press reported that there is some kind of exception for Wikipedia,
> open source software development platforms and online marketplaces.
> However, OpenStreetMap data is not only used by the non-profit
> OpenStreetMap Foundation but also by various other data consumers, most
> of them for-profit businesses.
> 
> FOSSGIS e.V., the OSMF local chapter in Germany, takes a stand
> against it by responding to every tenth tile requests to
> tile.openstreetmap.de with a special black error tile.
> 
> https://wiki.openstreetmap.org/wiki/File:Savetheinternet.svg
> 
> See it in action on any page using our tile server, e.g.
> https://www.openstreetmap.de/karte.html
> 
> The tiles are distributed randomly over the map.
> 
> 
> *Why does this affect the OSMF?*
> The UK will leave the European Union but it is likely that many EU rules
> will nonetheless apply in the UK as well, depending on how the
> negotiations continue.
> 
> 
> *What should the OSMF do?*
> I myself think that the OSMF should show at least a banner on
> openstreetmap.org instead of the usual conference banners – ideally
> ignoring cookie settings and showing it to every visitor for about three
> days.
> 
> 
> *What more could the OSMF do?*
> The OSMF could go even further and answer one of ten requests to its
> European (or all) tile caches with a black or grey error tile showing a
> short URL of a page containing more info

Re: [OSM-talk] Error on OSM

[Michael Reichert]

Hi

Am 05.09.2018 um 16:56 schrieb Stadia Arcadia:
> Hi, "Tribune Colombier" of Stade Raymond-Kopa now has the same size as
> "Tribune Coubertin". Is now has a square shape. The old stand has been
> replaced with a new one. Who can fix this? I'm a member of OSM, but I can't
> get it fixed. Who can do it for me? I'd really appreciate that. Thanks for
> the help already.
> 
> https://www.openstreetmap.org/#map=19/47.46040/-0.53094&layers=N

Please stop this spamming and don't create a new thread for each issue!

Instead, select the first email you send to this mailing list, click on
"respond" and write any further issues in that email.

Are you somehow related to Bas Mooz? Is this your workmate?

https://lists.openstreetmap.org/pipermail/imports/2018-July/005612.html

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Michael Reichert]

Hi,

Am 2018-08-09 um 22:48 schrieb Vao Matua:
> The Tanzania Development trust has calculated the Plus Code addresses for
> 17 million building points in Tanzania and have added a sample village
> (1800 points) as a test.
> https://www.openstreetmap.org/changeset/59213224
> 
> The Python code on Github works great to calculate Plus Codes.
> 
> We did used these tags:
> addr:pluscode:full  (the 8+2 digit full Plus Code)
> addr:pluscode:area (the first 4 digits of the full Plus Code which is a 1
> degree by 1 degree lat long area)
> addr:pluscode:local (the second 4 digits + last 2 digits which used with a
> local name becomes the local address)

There is no need for this data in OSM because the data can be retrieved
automatically from latitude and longitude (plain coordinates) which are
already assigned to anything which has a location on the planet.

Adding Plus Code tags to OSM objects is as useful as adding latitude=*
and longitude=* or any other coordinate system which can be calculated
from latitude and longitude.

This import should be reverted.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Draft Terms of use for the OSM website, API and other services

[Michael Reichert]

Hi Simon, dear other LWG members,

Am 29.07.2018 um 08:08 schrieb Simon Poole:
> Thanks to work by Kathleen Lu we have a draft Terms of Use document.
> 
> https://docs.google.com/document/d/1xtPjrTj09vQLloKmzyf-H-5mKtqh-vbPjsxE-5YRF5g/edit?usp=sharing
> 
> 
> This is a first for OSM given that we've never really spelled out
> anything with respect to using the API and website up to now, outside of
> the more technical aspects in the acceptable use documents.
> 
> The main motivation for this is driven by the GDPR related changes (not
> trying to identify users, restrictions on use by minors and so on), but
> there are certain rules that we should have probably been explicit about
> all along too. We expect that all access to the website, API and other
> services will be contingent on having agreed to the terms.
> 
> Comments are welcome, best per mail or specific comments on the document.

I read the draft and I think that is far too long. It does not invited
to be read by the users. This can lead to following issues:

- Users don't read it because it is too boring, too long and too
difficult to understand (especially for the majority being not native
English speakers or understanding no English at all). They would be
surprised by the important parts later.
- Already active members of the community refuse to accept the terms
because they don't understand the needs and the content.

If we need all that rules written down there, we should add a summary of
the points which are most important from our point of view at the
beginning. It could look like this:

- You have access to personal data (OSM metadata). Please handle it
appropriate.
- Your contributions must not violate copyright.
- You must be 16 years or older to join OSM.
- We don't guarantee anything. [insert better wording here]

The OSMF has already a block policy ruling when users get blocked
permanently and how. If we add terms to the website, we should integrate
the block policy into the terms. This has the advantage that user
actively agree the block policy which makes it a lot easier to use it in
court (I am not talking about a fictional case here).

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] User deleting abandoned and rejected proposals on the wiki

[Michael Reichert]

Hi,

I (Mateusz Konieczny was faster) found a user who removes all content
from abandoned and rejected proposal pages on the wiki and adds the
Delete template. It's the template asking a administrator to delete the
page. I think that our admins are clever enough to not blindly follow
these requests but his edits cause unnecessary workload for them and
make it difficult to use the wiki.

I would appreciate it if someone else reading this email could comment
on his talk page. Maybe we are able to convince him why he is wrong.

https://wiki.openstreetmap.org/wiki/User_talk:Adamant1

https://wiki.openstreetmap.org/wiki/Special:Contributions/Adamant1

These are some of the affected wiki pages:

*Proposal pages*
Proposed features/Adult services ‎(shop=adult and other, has not reached
RFC for 8 years)
Proposed features/parking aisle (highway=parking_aisle, rejected, has
become obselete by service=parking_aisle)
Proposed features/Bag shop (shop=bag, tag in use, proposal abandoned)
Proposed features/boat=private (boat=private, has not reached RFC since
2008)
Proposed features/Marked trail (marked_trail=, has not reached
RFC since 2008/2009)
Proposed_features/Fire_Hydrant (amenity=fire_hydrant, rejected in 2010,
12,000–14,000 objects from 2010 to 2015 in the database)
Proposed features/Driving pleasure (Driving_pleasure=1/2/3/4/5,
cancelled in 2010)
Proposed_features/agricultural_access (access=agricultural, proposal
never left draft state but 120,000 objects in the database)
Proposed_features/4th_Dimension (incomplete proposal from 2009 but long
discussion page)

*Documentation and other pages about "outdated software"
- Potlatch_1/Development_overview/GPS_tracks
- a lot of pages about Kosmos (predecessor of Maperitive), mainly
rendering rules

*Old events*
South_East_London_Mapping_Party (mapping party in 2008)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*

[Michael Reichert]

Hi Mateusz,

Am 02.07.2018 um 19:42 schrieb Mateusz Konieczny:
> Please comment - especially if there are any problems with this idea. 
> Please also comment if you support this edit, in case of no response
> at all edit will not be made as there would be no evidence that
> this idea is supported.

There are 177,152 FIXME and 1,216,043 fixme according to Taginfo. I did
not have a closer look on the average age of FIXMEs and fixmes.

What's the benefit in this mechanical edit? It just sets the
last_modified attribute to a recent date and data consumers, mappers and
QA tools get the impression that the object is not old.

FIXME should make alarm bells ring in validator tools because its key
only contains uppercase characters.

If you want to search for uses of FIXME, use the OSM Inspector. It
supports FIXME case-insensitive for about ten years now (even our new
C++ implementation does). It does not matter if you write FiXmE, fIXMe
or FixmE. Btw, todo=* (lower case only) is also supported.

http://tools.geofabrik.de/osmi/?view=tagging&lon=8.48813&lat=49.06482&zoom=11&overlays=fixmes_on_nodes,fixmes_on_ways

Fixmes tend to become the new trash piles in our streets. Lets go out
and fix them (yeah, the map is quite/too full of them).

I would love to see your energy going into a tool to bring OSM notes and
fixmes together and making mappers to get them into their

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed mechanical edit - moving building=building to building=yes

[Michael Reichert]

Hi Mateusz,

Am 2018-06-09 um 16:20 schrieb Mateusz Konieczny:
> So, is analysis by  Christoph Hormann
> 
> sufficient for this proposed edit?

Yes

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed mechanical edit - moving building=building to building=yes

[Michael Reichert]

Hi Mateusz,

Am 2018-06-09 um 12:17 schrieb Mateusz Konieczny:
> Are you aware about any analysis like that?
> 
> 
> 
> 
> I thought about
> 
> 
> 
> 
> 
> - listing top contributors
> 
> - time distribution graph (when tag was added)
> 
> 
> - distribution of editors used to enter data
> 
> 
> - maybe publishing also raw data used in analysis
> 
> 
> 
> 
> It should be fairly simple to write tool that
> 
> will give this info based on a simple 
> 
> 
> analysis (it would give statistics about 
> 
> 
> changes that caused tag to occur, without
> 
> special handling of reverts).

I did not expect you to write such a tool. It would be ok to pick some
random samples and look into their history.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed mechanical edit - moving building=building to building=yes

[Michael Reichert]

Hi Mateusz,

Am 2018-06-08 um 19:19 schrieb Mateusz Konieczny:
> building=yes is a standard way to mark building without specifying its
> type. Editors wishing to specify building type would (directly or
> indirectly, for example using StreetComplete) look through buildings
> tagged as building=yes.
> 
> building=building is an unexpected way to mark building without
> specifying its type and therefore retagging this duplicate to
> building=yes would improve tagging without any information loss.

Did you investigate who used that tag and maybe why? Was it a bot, a
editor preset, an import or manual user input? I would like to have this
question answered before a mechanical edit.

IMHO Any good mechanical edit correcting "wrong tagging" should do some
investigation of that kind.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi Rory,

Am 2018-04-24 um 18:27 schrieb Rory McCann:
> 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".

The current usage of unisex=* doesn't seem to be good tag design but
changing its definition isn't a good idea either. Your proposed
redefinition of unisex=yes would change the meaning of an established
and highly used tag. Please invent new tags.

Sorry for the stupid question but are there more types of toilets than
the following three?
- male only
- female only
- not assigned to a specific gender

If the world were that simple, the following scheme might be sufficient:

amenity=toilet + unisex=yes + toilet:male_only=no +
toilet:female_only=no: one room for all

amenity=toilet + unisex=yes + toilet:male_only=yes +
toilet:female_only=yes: the "standard" toilet with separated rooms for
women and men

amenity=toilet + unisex=yes + toilet:male_only=yes +
toilet:female_only=yes + toilet:all=yes: toilet with three rooms (men +
women + all)

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)





signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] New wave of Pokémon Go mappers – check the parks

[Michael Reichert]

Hi,

Pokémon Go seems to have updated its OpenStreetMap data [1] leading to
an higher than usual number of new mapppers adding parks – some or many
of them are fictional. It is a good idea to check
http://resultmaps.neis-one.org/newestosm for your country (click on the
flags to show only edits from your country) and use Overpass API queries
looking for ways tagged with like leisure=park, natural=grassland or
landuse=grass which have been modified recently.


This might be a suitable Overpass query.

[date:"2018-04-23T00:00:00Z"]
[timeout:120]
[bbox:{{bbox}}];
(
 way[leisure=park];
 rel[leisure=park];
 way[leisure=garden];
 rel[leisure=garden];
 way[recreation_ground];
 rel[recreation_ground];
 way[leisure=playground];
 rel[leisure=playground];
 way[leisure=pitch];
 rel[leisure=pitch];
 way[landuse=grass];
 rel[landuse=grass];
);
out geom meta;

Please be friendly even if all edits of a user are junk. Add a changeset
comment to all reverted changeset to inform other mappers that they can
continue reviewing other changesets and comment one of the changesets of
the newbie telling him that edits have to match the reality on the
ground. You might include a link to
https://blog.openstreetmap.org/2018/04/01/tips-pokemon-go-2/#

Best regards

Michael


[1]
https://www.reddit.com/r/TheSilphRoad/comments/8ehf8u/new_nests_osm_data_has_officially_changed_nests/


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] GDPR introduction

[Michael Reichert]

Hi Simon,

Am 2018-04-17 um 12:48 schrieb Simon Poole:
> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> * will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
> 
> The LWG has prepared a position paper on the matter that has been
> reviewed by data protection experts and in general the approach to not
> rely on explicit consent has been validated. It should be noted that
> while the paper outlines our approach, some of the details still need to
> be determined. In particular the future relationship with community and
> third party data consumers that utilize OSM meta-data and what will
> actually be dropped/made less accessible of the data listed in Appendix B.
> 
> LWG GDPR Position Paper
> 
> 
> Please feel free to discuss on the talk page
>  or on this list.

I would like to thank you for your work and agree that the OSMF should
not ignore GDPR. I think that it is a huge step forwards in terms of
data protection in general.

*Controller vs. processor*

Chapter "Recommendations", section 3 (page 10) writes:
> Using the data for user and contribution profiling will either require a data
> processing agreement (and a similar agreement for research) or the the OSM
> data consumer needs to operate as an independent data controller (see
> below)..

Does this mean that someone who runs a service to fight vandalism and
other bad edits has the choice to either sign a data processing
agreement with the OSMF or to work as independent data controller? I am
not sure because section 5 on the same page writes:
> Entities receiving full data (that is including metadata) are expected to 
> operate as
> independent controllers.

Working as data processor has the disadvantage that the service provider
has to sign some piece of paper. On the other hand it provides safety
for them. If a service provider acts as data controller any OSM user can
ask him to delete his user data?

Users asking the service providers instead of the OSMF to delete their
data add addition hassle to the service provider and harm the
development of OSM:

- The service provider has to "filter" incoming data from OSM (diffs,
planet dump, …) to remove data they are not permitted to use.

- The community is unable to review edits of that user using the
third-party service because the user is not visible there. Users with
bad faith (they exist and I know a few examples) can use that to do
edits below the radar and make validation and reverts of their edits
difficult.

That's why I would like to ask the OSMF to let service providers choose
their favourite legal model. If the service provider chooses to be a
data processor, he can redirect incoming request of deletion to the OSMF
and the OSMF has to delete the user and block his account. The latter
makes further validation of his edits mostly unnecessary.


*Timestamps*

Appendix B writes:
> It can be argued that completely removing timestamps causes a significant 
> loss of
> functionality and information, for example when an object was last updated. 
> This
> could be partially rectified by simply reducing the granularity of the 
> timestamps in
> publicly available data, for example by only displaying dates.

Removing user names, user IDs and changesets from data dumps and general
API access does not really harm most usage of OSM. However, one change
might cause more trouble if it were seriously followed through – the
timestamps.

If you reduce their granularity to one day, it is still possible to
group edits in areas with a low density of mappers. I am not talking
about central Sahara, the poles or the Middle West of the U.S. I am
talking about almost all areas of Central and Western Europe except the
metropolitan areas.

See the following picture of my master thesis
https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png

It shows the frequency of map edits in the north-east of Germany between
2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
imported the hourly diffs from OSM into my database. Dark blue means
that within more than one month, less than four diffs contained updates
for that area. You would have to reduce the granularity to a month to
make the recreation of changesets impossible!

Slide 15 of
http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf
shows the same for California. It is possible to group edits in the Bay
Area if the granularity is reduced to one day.

I agree that timestamps can be used to group edits but it is not
possible to group them properly and you still don't know who uploaded
the changeset. That's where personal information begin

[OSM-talk] no_feature_tag_nodes

[Michael Reichert]

Hi Maarten,

I am the developer of that layer.

Am 13.04.2018 um 07:20 schrieb Maarten Deen:
> On 2018-04-13 05:02, Jack Armstrong dan...@sprynet.com wrote:
>> OSM Inspector tags some individual address nodes as errors. For
>> example, these nodes located inside the lateral boundaries of
>> buildings:
>>
>> https://www.openstreetmap.org/edit?node=5438712543#map=19/39.68899/-104.86454
>>
>>
>> I guess I'm reading it wrong, but I can't seem to locate anything
>> specifically on the wiki that refers to this. Is there some
>> documentation I can refer to which addresses this specific situation?
> 
> Maybe it's complaining about the description tag without having some
> other tag to indicate what this node is?

Jochen answered the question already.

That's the reason.

Node 5438712543 has a description tag. That tag should only be used if
the object represents something on the ground. If the node had a proper
feature tag (e.e. shop=*, amenity=*), it would be ok. However, your node
is just an address with a description.

The aim of the view is to find objects (usually POIs) lacking proper
tagging added by newbies and objects added by low-quality SEO spammers.

The list of good and bad tags can be found on the wiki or you look it up
in the source code.
https://github.com/geofabrik/osmi_simple_views/blob/master/src/tagging_view_handler.cpp#L360
I did a few iterations when I developed that view in order to get not
too much false positives. However, I don't know all "good" tags. So
please write an email to i...@geofabrik.de or create an issue on GitHub
or create a pull request if you think that a tag is missing.

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)





signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

Am 2018-01-12 um 17:01 schrieb Tobias Knerr:
> On 12.01.2018 15:39, Andy Townsend wrote:
>> More seriously, any automatic use of OSM messages is problematical
>> because it devalues the messages that we want people to actually read -
>> the ones that are composed by and sent be a human, and have actual
>> useful information in them
> 
> I agree. Right now, messages and comments sent via OSM channels tend to
> be written by humans for a specific individual recipient, which gives
> them a very good signal-to-noise ratio. I enjoy that a lot and would
> like to keep things that way.

We could introduce a special kind of changeset discussion comment which
does trigger email notification. Any comment which is automatically
generated should be such a "silent comment".

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

Am 2018-01-12 um 15:13 schrieb Bryan Housel:
> I love this feature, and I hope Wille keeps it in.
> The message is very well written, and it’s not spam if the user asks for 
> their changeset to be reviewed and then somebody actually does it.

It should be optional to post a changeset comment. If someone marks all
changesets in his home area as good, all changesets get a comment. If I
get a comment on all my changesets, I will write a filter on my personal
mail server to drop all these unsolicited emails (all comments with the
OSMCha default text). I can write filters on my own but I am sure that
many of our users are not able to do (or don't want to do and might
reduce their OSM activity).

Ideally, this comment should be localized. If a user uses the German
locale of his editor, he should the receive the comment in German if the
reviewer also uses a German locale (it is then very likely that they
would use German for their normal conversation). Receiving lots of
similar foreign-language comments is not far away from receiving ten
emails whose subject is "Bitcoin Millions".

That's why I consider it as some kind of spam (half of all recent
comments are just automatically generated):
http://resultmaps.neis-one.org/osm-discussions?c=Germany#6/51.727/9.338

All in all, the usage of the changeset discussions by OSMCha just points
out that a feature is missing on osm.org. This cannot be fully replaced
by a third-party application.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Automatically generated changeset discussion comments by OSMCha

[Michael Reichert]

Hi,

OSMCha started posting comments to changesets a few days ago when a user
marks a changeset as good or bad.
https://www.openstreetmap.org/user/wille/diary/43101
I would like to ask the author(s) of OSMCha to disable this feature.

We expect to read all mappers incoming message (personal messages and
changeset comments). If third-party tools start to post comments to lots
of changesets automatically, this is some kind of spamming. If OSM sends
to much emails to a user, the user will probably ignore them or treat
them as spam.

I think that OSMCha should not post a comment automatically except if
the user has explicitly asked for feedback or there are quality issues
regarding the edit (mistakes, vandalism, guideline violations or
anything else which makes it necessary to talk to the user).

I post this email to this mailing list instead of filing a bug report a
Github [1] because I want to bring this problem to the wider audience
and initiate a general discussion on the acceptable usage of the
changeset comments API.

What are your thoughts and opinions on this issue?

Best regards

Michael


[1] Btw, which Github repository would be the correct one the file the
bug report at?
https://duckduckgo.com/?q=osmcha+github&t=ffsb&ia=web


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi Yuri,

Am 13.11.2017 um 22:58 schrieb Yuri Astrakhan:
> Andy, I can only assume you agree with the rest of my argument. As for this
> case -- this is not a mechanical edit. Per definition. I looked at each of
> these three features, analyzed them, and thought this is a reasonable
> change. You could call it a mistake (I am human), but it cannot be called
> mechanical.

Here comes another of our unwritten rules into play. Even if a
systematical edit [1] is not a mechanical edit, it is sensible to
discuss it beforehand as if it were a mechanical edit (although you
could steps which involve the OSM wiki). This rule is unwritten but
people who have followed discussions on any relevant mailing list or
forum section will know it because some other users mentioned it there.
That's why silently reading discussions for a while before doing
possibly disruptive things in OSM is recommended (another unwritten rule).

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi Yuri,

Am 13.11.2017 um 13:20 schrieb Yuri Astrakhan:
> Christoph, I don't think this works for any community that grows beyond a
> certain size, especially when the community is not in the same
> location/building/land otherwise, and doesn't see each other every day.
> Look at Wikipedia, or any large social organization for that matter. At the
> village/startup level, you have very few codified rules, but as the group
> grows to a city/corporation size, it becomes more and more bureaucratic. We
> may not like it, but clear rules help community maintain cohesion, and
> prevents many conflicts.

No, it works. It works if someone is considerate and mindful and listens
(reads) what people write on mailing lists and forums. That's how I
learned how OSM works. I have read the mailing lists (Talk-de when it
was one of the most active mailing lists) and the German forum and
learned a lot of unwritten rules there. For example, the AGF rule, the
on the ground rule, to be friendly with newbies, not to blindly trust
satellite imagery and so on.

But if someone just bursts into a community instead of feeling his way,
it won't be a surprise if he violates a dozen of unwritten social rules
with one single action.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Dispute on wiki page Collaboration_with_Wikipedia

[Michael Reichert]

Hi,

I have a dispute with user Verdy_p on the sections "Importing geodata
from Wikipedia" and "Importing geodata to Wikipedia" of the wiki page
https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia and
would like to get comments from other members of the OSM community
because edit wars are a waste of time.

That's the state before I started editing yesterday:
https://wiki.openstreetmap.org/w/index.php?title=Collaboration_with_Wikipedia&oldid=1515024
That's the state after my changes:
https://wiki.openstreetmap.org/w/index.php?title=Collaboration_with_Wikipedia&oldid=1521333

I added two red warning Ambox templates to make clear that we do not
copy data from Wikipedia (see Mateusz's posting on the legal situation
of imports from Wikidata which is pretty similar
https://lists.openstreetmap.org/pipermail/talk/2017-November/079492.html).
In addition I shorted the section "Importing geodata to Wikipedia".

I think that the section "Importing geodata to Wikipedia" is a mess and
found it difficult to read. It contained lots of information which is
not necessary for OSM. I think that the question if someone may copy
data from OSM/Wikipedia/Wikidata to Wikipedia or Wikidata should not be
discussed in the OSM wiki in full length. Instead, the wiki should link
to a page at *.wikipedia.org or *.wikidata.org or the WMF wiki/website.
If the opinion of the OSM Foundation differs, it should be mentioned or
linked from the OSM wiki. Any further discussions whether two licenses
are compatible and how relicensing of the content of Wikipedia works
should be discussed outside the wiki (at a blog, mailinglist or personal
website).

It happened as I expected. Verdy_p restored the deleted sections.

What is your opinion?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Michael Reichert]

Hi Ryszard,

Am 2017-10-12 um 22:41 schrieb Ryszard Mikke:
> On 3 October 2017 at 18:56, Christoph Hormann  wrote:
> 
>> On Tuesday 03 October 2017, Frederik Ramm wrote:
>>> Hi,
>>>
>>>seeing that the matter is discussed quite intensively and opinions
>>> vary widely, could we perhaps agree to pause any (large scale)
>>> wikidata edits for a while until more members of our community have
>>> had a chance to form an opinion?
>>
>> I think that is a good idea.
>>
> 
> I'm not happy with it, as the way I do it is sensitive to amount of data to
> work with, so if I don't run it regularly, I have to restart from fragments.
> But well, I might limit the query to Poland where the adding of wikidata
> entries is widely accepted.
> I will repeat Yuri's question here:
> If a specific community is ok with it, does it override world wide ban for
> that location?

Please pause your edits of such kind at all!

If a part of the OSM community thinks that an edit of type X is good but
another part of the community opposes, there is not enough consent on
the topic. The question if we shold have wikidata=* tags in OSM and
which objects should have them, is an international questions. As long
as international discussions are going on, everyone has to wait.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Michael Reichert]

Hi Ryszard,

Am 2017-10-13 um 01:11 schrieb Ryszard Mikke:
> On 12 October 2017 at 23:23, Christoph Hormann  wrote:
> 
>> As i have pointed out elsewhere doing QA in OSM based on Wikidata does
>> not in any way depend on the automatic addition of Wikidata IDs to
>> OSM - or in other words: Any ID you'd add based on some matching
>> algorithm just for QA purposes you would not need to add at all.
>>
> 
> How exactly would you approach detecting OSM objects with wikipedia=*
> pointing to disambiguation page in wikipedia, instead of the correct one,
> without using wikidata? This is a real problem - e.g. wikipedia link
> "pl:Józefów" is useless as it points to a list of about a hundred places of
> this name. With wikidata one can locate all similar cases and correct them
> - I have done this for Poland as well as for other countries, using Yuri's
> QA tool. Without it, disambig wikipedia links would stay there until
> someone accidentally finds one and will be willing to correct it. One by
> one. There were hundreds of such cases in Poland alone.

You don't need an additional key in OpenStreetMap to find wikipedia=*
tags pointing to disambiguation pages. By parsing the content of the
Wikipedia page and checking if the page looks like a disambiguation page.

And even if detecting disambiguation pages in Wikipedia would miss too
much of them, you could use Wikidata to check if the Wikipedia page the
Wikidata item points to is a disambiguation page according to Wikidata?

While wroting the paragraph above, I wondered how the status of a
Wikipedia page a Wikidata item links to is maintained. Is there a bot
updating them every hour in Wikidata? If there is no such bot (or it is
not running every minute or hour), there is no need for wikidata=* tags
in OSM to find wikipedia=* tags pointing to disambiguation pages because
you could get the status of a Wikipedia page by parsing the Wikipedia
page itself.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi Yuri,

Am 2017-10-13 um 23:25 schrieb Yuri Astrakhan:
> I would like to introduce a new quick-fix editing service.  It allows users
> to generate a list of editing suggestions using a query, review each
> suggestion one by one, and click "Save" on each change if they think it's a
> good edit.
> 
> For example, RU community wants to convert  amenity=sanatorium  ->
> leisure=resort + resort=sanatorium.  Clicking on a dot shows a popup with
> the suggested edit. If you think the edit is correct, simply click Save.
> Try it:  http://tinyurl.com/y8mzvk84
> 
> I have started a Quick fixes wiki page, where we can share and discuss
> quick fix ideas.
> * Quick fixes 
> * Documentation
> 

Which created_by=* tag does your editor set on the changesets?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] All the subway systems in the world

[Michael Reichert]

Hi Ilya,

Am 2017-10-08 um 14:53 schrieb Ilya Zverev:
> Michael, this is the first time I'm hearing about that light_rail 
> controversy. It is documented somewhere? If not, why does it make my proposal 
> worse?

Dig a little bit in the history of the wiki page and you will see the
edit wars.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&action=history
The current version contains light_rail.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] All the subway systems in the world

[Michael Reichert]

Hi,

Am 2017-10-07 um 09:11 schrieb Roland Olbricht:
> I strongly suggest to oppose the proposal. To do so, you need to add
> 
> {{vote|no}} --[[User:|]] date
> 
> under the headline == Voting == once voting is opened. Said in short:
> Adding more contradictions and confusion in public transport mapping
> makes a too complex topic worse in terms of complexity.
> 
> In detail, there is a whole bunch of reasons
> 
> […]

I agree with the reasons given by Roland although I would not write them
that harsh.

There is another reason why I oppose. The proposals suggests the usage
of light_rail=yes and route=light_rail but the Public Transport version
2 schema it is based on does not contain the route type "light_rail".
That type was added after the voting (not by the author of the
proposal). I don't really know why the original proposal does not
contain this type but "light_rail" was abused a lot at that time
(2010/2011), mainly for many German S-Bahn systems which are normal trains.

Thank you, user Weide, for pointing me to this issue.
https://forum.openstreetmap.org/viewtopic.php?pid=666777#p666777

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] All the subway systems in the world

[Michael Reichert]

Hi Ilya,

Am 30.09.2017 um 18:35 schrieb Ilya Zverev:
> I have made a script that parses and validates subway systems. It prints the 
> number of subway lines and stations that an automated system can extract from 
> the OpenStreetMap data. See the latest report here (these are updated 
> manually for now):
> 
> http://osmz.ru/subways/
> 
> It is still in beta: it doesn't use networks and omits many non-european 
> cities. We plan to employ it for maps.me, so it would be the first app that 
> does world-wide subway routing using only OSM data. To make tagging subway 
> systems uniform and usable, I've compiled a list of practices on this page:

Why does your validator find lots of errors on the S-Bahn relations in
Berlin? I don't understand what's wrong with:
> stop node 1806004219 is not connected to a station in route (relation 14981, 
> "S-Bahnlinie S41: Innenring im Uhrzeigersinn")

The stop node is on a way referenced by the route relation.

Best regards

Michael


PS I am working on a Public Transport version 2 validator, too.
https://github.com/geofabrik/osmi_pubtrans3

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] All the subway systems in the world

[Michael Reichert]

Hi Ilya,

Am 30.09.2017 um 18:35 schrieb Ilya Zverev:
> Some questions are answered on the Talk page there. Next week I'll open a 
> voting, so that tagging schema could be made official. 

You are aware that the RFC phase has to bee at least two weeks long?

https://wiki.openstreetmap.org/wiki/Proposal_process#Voting

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overlapping brands (was "Fixing wiki* -> brand:wiki*")

[Michael Reichert]

Hi Andy,

Am 2017-09-27 um 17:57 schrieb Andy Townsend:
> On 27/09/2017 15:35, John F. Eldredge wrote:
>> The spatial information will tell you where each business location is;
>> it is not sufficient to tell you whether these are multiple locations
>> of the same brand, or two unrelated brands that share the same name
>> and category of business.
> 
> Can anyone think of an example where two unrelated brands share the same
> name and category of business in the same geographical area?

Netto in Germany. Both companies have shops in some German states.
Officially, one of them is called "Netto Marken-Discount" and the other
one just "Netto". But people call them both "Netto" and there are
multiple towns and cities which have both Netto and Netto shops. Because
you cannot expect any OSM mapper to add more than name=* and
shop=supermarket, you cannot decided without additional sources which
brand a Netto supermarket belongs to.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Michael Reichert]

Hi Martin,

Am 2017-10-03 um 00:28 schrieb Martin Koppenhoefer:
> indeed it’s not helping the quality if editors are not familiar with the 
> language specifics for the area of the things they edit (this is true for all 
> UGC, be it osm, wikidata, etc). Aldi Sud does not make sense, it’s either Süd 
> or, if you really have to (e.g. domain names), Sued. 
> https://www.wikidata.org/wiki/Q41171672
> 
> This kind of fiddling leads to objects like this: 
> https://www.wikidata.org/wiki/Q125054
> inception 1913
> founded by Karl and Theo Albrecht, born 1920 and 1922. 
> Founded 7/9 years before their birth?
> 
> It is also not true that aldi nord and süd result or follow from the 
> splitting of Aldi, they result from the split of Albrecht KG. Not even the 
> founding year 1960 for the parts is correct, it’s 1961 (according to wp and 
> company website)
> 
> It also still claims Aldi is a GmbH & Co. KG and even has 1 reference for 
> this (german wikipedia), while the German wikipedia actually has a long 
> paragraph trying to explain the structure and saying there are 66 different 
> regional GmbH & Co. KG, plus other companies like the ALDI Einkauf GmbH & Co. 
> oHG or the ALDI SÜD Dienstleistungs-GmbH & Co. oHG, i.e. it’s a group of 
> companies, a concern.
> Here’s a list of parts of Aldi Süd:
> https://unternehmen.aldi-sued.de/de/impressum/
> 
> It can all be fixed of course, but I’m curious how all these errors have 
> gotten there. There’s still more wrong than correct in this object.

The wrong name (Sud instead of Sued or Süd) was added by user
Pingsonthewing who probably does not live in Germany or any other German
speaking country but tries to actively push Wikidata into OSM.
https://www.wikidata.org/w/index.php?title=Q41171672&oldid=567343632

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

[Michael Reichert]

Hi,

Am 2017-09-26 um 09:19 schrieb SwiftFast:
> I need to download all version 3 bus stops in a country which has about
> 30,000 bus stops. Version 3 exists since a 2012 import. What's the
> recommended way to accomplish this? I have two ways in mind.

Version 3 of what?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Awards 2017

[Michael Reichert]

Hi Ilya,

Am 18.06.2017 um 11:05 schrieb Ilya Zverev:
> This year the nominees for the short list will be decided not by a
> single committee, but by a separate groups of people. For example, the
> Innovations award will be manager by the Engineering Working Group, and
> the Writing award — by the Communications WG.

It is good to extend the committee.

> We don't have selection committees for mapping, community and regional
> awards, so if you want to participate, please contact me. Note that this
> will exclude you from the list of nominees.
> 
> 
> The call for nominees will close on 9th of July, and shortly after that
> we will start the second round, choosing the award recipients.

I observed that my nomination disappeared. I assume that the selection
is happening currently, isn't it? You mentioned the possible committees
for two categories but I don't know the remaining ones.

Of course, some selection has to happen because some nominations are
just invalid (e.g. WeeklyOSM was nominated but was awarded last year).
But I think that the selection should happen by the community and not by
committees in the dark. If they sort out nominees, it would improve
transparency very much and reduce (my) anger if they gave a short
explanation. I don't expect a long essay, a simple "was awarded last
year" or a sentence which explains why he/she does not fit into the
category is good enough.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Responding to vandalism

[Michael Reichert]

Hi Manohar,

Am 2017-03-16 um 14:47 schrieb Manohar Erikipati:
> - DWG currently acts promptly on incidents reported via email, but we
> need a more accessible mechanism that allows new users to report such
> incidents directly from the website or editors. The email details and
> existence of DWG, is only available currently in the wiki [3]

There was a GSoC project about a "report" button two years ago, wasn't it?

> - Auto-blocking known vandals to prevent repeated attacks [4]

No! We are not the German Wikipedia. Users should only be blocked after
two humans verified that a user block is reasonable. Don't do
overblocking. Most of the overblocked users won't try to lift their block.

> - More visibility, awareness of QA tools and history tab on the OSM
> homepage. Most of the really powerful QA tools like osmhv and osmose
> are only known to advanced users.

That's a desing problem of osm.org. The website is too much focussed on
the map. The full opposite is openstreetmap.de (only available in German
and needs some care) which highlights that OSM is a collection of
projects, not a map.

> It would be great to hear more approaches that could protect the map
> against common mistakes and intentional attacks. Much of the world
> lacks an active mapping community, so it is up to a small set of power
> mappers to catch and revert most of the bad edits [6]. Building better
> support systems to respond to bad edits could help more experienced
> mappers focus on community building activities.
> 
> 
> [1] https://www.openstreetmap.org/user/PlaneMad/diary/40491
> [2] https://github.com/mapsme/omim/issues/4188
> [3] https://wiki.openstreetmap.org/wiki/Vandalism
> [4] https://en.wikipedia.org/wiki/Wikipedia:Autoblock
> [5] http://wiki.openstreetmap.org/wiki/List_of_Vandalism_Changesets
> [6] 
> http://osmcha.mapbox.com/?usernames=woodpeck_repair%2C+zool%2C+SomeoneElse_Revert%2C+mavl%2C+pnorman_mechanical%2C+_sev%2C+OSMF+Data+Working+Group%2C+Peda%2C+FTA_dwg%2C+Deanna+Earley%2C+Firefishy_repair%2C+drolbr%2C+emacsen_dwg%2C+sly&is_suspect=False&is_whitelisted=All&checked=False

Your list contains only DWG members. There is a handful of mappers who
also clean up bad edits and work as an unorganized protection shield of
DWG, i.e. they comment and clean and only contact the DWG if they need a
user block. Some of them use dedicated revert accounts:

DD1GJ,Nakaner-repair,highflyer74,BeKri,tux67

Btw, using a revert account like I do it, is a good idea. It keeps your
statistics clean.

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)




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Responding to vandalism

[Michael Reichert]

Hi,

Am 2017-03-16 um 15:48 schrieb Clifford Snow:
> Manohar,
> My experience is most of these edits can be cleaned up easily with simple
> edits. Some need full reverting, which can be done using JOSM, while others
> need careful pruning of the bad but leaving the good. I've fixed numerous
> pokemon edits in Washington State. I've only had to go to DWG 2or 3 time. I
> don't think we need to involve DWG in every case.
>
> I've send changeset comments and messages. Other than one belligerent
> individual who promised to report me if I kept reverting his phony edits,
> I've never heard back from any of them. There have been a number of example
> of appropriate changeset comments posted on talk and talk-us that let the
> mapper know the behavior isn't appreciated but also encourages them to
> become an active contributor. I suspect pokemon players could become
> prolific mappers.

I can second that. I did Pokémon cleaning in Germany. The majority of
them doesn't edit OSM a second time. Some of the do, therefore I add all
users whose edits I reverted to my RSS feed reader for a few weeks to
check if future edits are ok. I had three cases when those users
continued mapping. Only one of them really needed a 0-hour block to read
his changeset comments.

> A tool that flags new parks, don't just look for named parks, but all parks
> - some of the players haven't gotten the word that it's only named parks,
> and new water features would be useful. Right now Ian Dees has a bot
> running on slack [1] and IRC[2] that picks up new users from the changeset
> feed. Sure it would be nice of someone could develop a similar bot to watch
> for new users adding pokemon features. But until we have that tool we
> really need to encourage more people to watch edits in their area.

A tool which looks for the editing patterns currently used by Pokémon
mappers would be very good. What about an additional filter for OSMCHA?
The filter should be adapted if the editing pattern changes, i.e. some
mappers should look what Pokémon player are currently discussing about
on the social media (i.e. do spying).

> [1] https://osmus.slack.com/messages/new-mappers
> [2]  irc://irc.oftc.net #osm-bot

You can also use http://resultmaps.neis-one.org/newestosm?c=Germany to
look for new mappers. If you review changesets by newbies, please write
a changeset comment that you reverted the edits if you did it. You
should be honest towards the user whose edits you reverted and other
reviewers are happy if they don't have to review a changeset which has
already been reverted.

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)




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fixing broken multipolygons

[Michael Reichert]

Hi,

Am 03.03.2017 um 17:27 schrieb Sebastiaan Couwenberg:
> Are there plans to make these challenges permanent or periodically
> re-introduce them when a new batch of issues has been prepared?

The German speaking countries have a handful of mappers who regularly
look for multipolygon errors using OSMI. Just have a look at the Areas
view of OSMI at the border of Germany and the Netherlands.

http://tools.geofabrik.de/osmi/?view=areas&lon=6.68088&lat=52.16821&zoom=9

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Cleanup of Wiki Page "Contact_channels"

[Michael Reichert]

Hi Simon,

Am 12.12.2016 um 21:47 schrieb Simon Poole:
> Like so many wiki pages there is really only one good action: send it to
> the circular folder.
> 
> https://www.openstreetmap.org/help already lists all OSMF operated
> services, and at SOTM we discussed that we might add in one way of the
> other a pointer to the preferred national comms channel. Lets simply
> keep that up-to-date.

This means that I should tidy up this wiki page by deleting almost
everything, writing a few new words and adding thick, big link to
https://www.openstreetmap.org/help? Before I do that, I will write a
pull request to the website to add the missing information at osm.org/help:
- link to bugtrackers (I will write it like "to report software bugs of
the website and other software)
- notes (to name a method to inform us about map errors)
- changeset discussion (to discuss a single map change somebody did)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Cleanup of Wiki Page "Contact_channels"

[Michael Reichert]

Hi,

I just wanted to paste the link to
https://wiki.openstreetmap.org/wiki/Contact_channels into a message to a
newbie and checked if the content of page is up-to-date. By checking the
page some questions arised:

The page lists three XMPP channels. I checked if the English and the
Austrian are still in use. The English channel is out of use. The last
message is from 2016-11-22. There is currently about *one* message per
month. When I joined today, one other user was online. (#osm at
irc.oftc.net has 250 users and is active based on my own observations)

I was unable to check Austrian channel. My account at jabber.ccc.de is
not able to join, I get an error 403.

I did not check the Slovakian channel.

Are there any objections against moving the English channel into a
section called "formerly used communication channels"?

The page also lists a Teamspeak server. Because I avoid to install
proprietary software on my computer, I cannot test if it is in use. Are
there any objections against moving it to the section "formerly used
communication channels"? I have never heard of the use of Teamspeak for
communication inside the OpenStreetMap project.

I will drop a note on the Talk page of that wiki page for those people
who are interested in that page but do not read this mailing list.

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)




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Central Place to Reach Wiki Administrators?

[Michael Reichert]

Hi,

is there any method to reach all administrators of the OSM Wiki [1] in
one go, e.g. to ask them to block a user? Currently, I have to select
one of them and ask him at his personal discussion page. But if he has
more important things to do, it may take some time until he reacts.
Therefore, it is a game of change to reach them.

The Data Working Group offers a central way to reach its members, it's
d...@osmfoundation.org

A central discussion page where to place messages to the administrators
would help.

Best regards

Michael

[1] https://wiki.openstreetmap.org/wiki/Special:ListUsers/sysop

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] International mapping getting together day

[Michael Reichert]

Hi Andrew,

Am 2016-09-30 um 21:43 schrieb Andrew Hain:
> Any interest in organising a distributed mapping party where we get together 
> round the world, attracting armchair mappers who haven't experienced field 
> mapping or just people with a casual interest? It could be a chance to 
> promote ourselves as the full extent of our project or we could have a 
> particular topic that we attract mapping of.

user !i! organized The Night of the Living Maps on 7th February 2012 [1]
and Operation Cowboy on 23–25th November 2012 [2]. Both were remote
mapping events—we call them nowadays (and even at that time) "mapathons".

> This would take a little time to get organised, maybe even into 2017.

A date during late spring, summer or early autumn (i.e. May until
September) is best because that's the time when there is good weather in
the areas were most of the mapping population lives. (I know that there
are also mappers in India, Africa, Latin America etc.)

Do you know that annual OSM birthday is the date every year which is
good (but not best) for such a distributed event? It is not the best
date because in some countries there are holidays in August.

Best regards

Michael


[1] https://wiki.openstreetmap.org/wiki/Night_of_the_living_maps
[2] https://wiki.openstreetmap.org/wiki/Operation_Cowboy



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] SotM Group Photo without Logo

[Michael Reichert]

Hi,

for the upcoming WeeklyOSM and Wochennotiz issue 323 we, the team of
WeeklyOSM and Wochennotiz, would like to use the group photo of State of
the Map in Brussels.

https://wiki.openstreetmap.org/wiki/File:State_Of_The_Map_2016_group_photo.jpg

Unfortunately, the photo published at OSM wiki contains the SotM logo at
the upper left corner which we do not want to have inside the image (we
want to crop a little bit different). I remember to have seen it at
Flickr (uploaded by Tatiana?) but I do not find it any more.

Could someone either send the photo without the logo to
b...@openstreetmap.de (the mailing list of Wochennotiz) or upload it to
the wiki and post the link here? Thanks.

By the way, please add all the photos you upload to a suitable category
by adding [[Category:State_of_the_Map_2016]] to the file description.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Neutrality of SotM

[Michael Reichert]

Hi,

could someone who is member of SotM Working Group explain me, why the
Twitter account of SotM promotes voting for Ramani Huria at OSM Award?
It is ok that SotM promotes OSM Award itself but it should not promote
some candidates and others not.

@sotm has retweeted following tweets:
https://twitter.com/RamaniHuria/status/773841822309285888
> 1/4. @openstreetmap launched #OSMAwards http://bit.ly/2cmPAZH  to be
> presented at the @sotm conference in Brussels.

https://twitter.com/RamaniHuria/status/773842098307080192
> 2/4. And @RamaniHuria is nominated under the category "Greatness in
> Mapping Award".

https://twitter.com/RamaniHuria/status/773842401203019776
> 3/4 We'd like to thank the @openstreetmap community for considering
> @RamaniHuria for this award, it's a great honor to be nominated.

https://twitter.com/RamaniHuria/status/773842658028642304
> 4/4. Please consider voting, place your vote here
> http://awards.osmz.ru/voting  and we hope to see you in Brussels at
> @sotm 2016 conference

Please remove this (re)tweets in order to keep the competition fair.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] SearchAroundBot: a Telegram Bot for OSM

[Michael Reichert]

Hi Frederik,

Am 24.08.2016 um 23:16 schrieb Frederik Ramm:
> On 08/24/2016 03:18 PM, Nicolás Alvarez wrote:
>>> Please ensure that everyone who contributes data to OSM with this bot
>>> actually has got an OSM account (and hence has agreed to the OSM
>>> contributor terms), and that the data is contributed using that OSM
>>> account (not a generic account that you have created), and that they can
>>> be reached by OSM user-to-user messaging if necessary.
> 
>> Aren't there several cases where this isn't followed, like Wheelmap?
> 
> Wheelmap is the only case I know of. If you know of more, please tell.

Kort and Beermap. Kort has a difficult review mechanism and therefore
has few contributions to OSM. Beermap edits name, beer types and wifi
access.

> The wheelmap case has been much discussed and their "wheelmap visitor"
> edits are tolerated because they never add new objects, and only
> add/modify one single tag between one of three settings. 

wheelmap_visitor nowadays also adds/edits toilets:wheelchair=*.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Michael Reichert]

Hi Eric,

Am 14.07.2016 um 17:19 schrieb Éric Gillet:
> However I'd believe that there is (in Europe for the example's sake) a very
> low number of restaurant really named McDonalds and not part of the
> franchise. So if the changeset correct 300 restaurants but 2 are "damaged"
> by the automated edit, would the edit be bad enough to be reverted or not
> be done in the first place ?

A mechanical edit must not cause damage. Therefore a mechanical edit
which has damaged some data (damage > 0) should be reverted.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automated edits code of conduct

[Michael Reichert]

Hi Éric,

Am 10.07.2016 um 23:26 schrieb Éric Gillet:
> OSM contributions must follow the Contributor Terms
> ; these
> therms are being shown to new users and they must explicitely accept them
> before they can start contributing.
> 
> However, another distinct set of rules is also being enforced by the DWG :
> the Automated edits code of conduct
> 
>  (AECoC).
> 
> In contrary to the Contributor Terms, these rules :
> 
>- Are not shown to new contributors

It is shown to new contributors, not directly but they get informed. If
you create an account, you will see a welcome page after clicking on the
confirmation link which you get via email. This page explains basic
things like the data model (node, way, relation) and says that there are
special rules for imports and mechanical edits.

>- Are not accepted by new or existing contributors
>- Doesn't seem to have been voted on before their "establishment"

There are dozens of other rules which have neither been voted nor being
accepted by every contributor. Just have a look at Good_Practice at OSM
wiki. None of those items has been voted. They are basic rules.

The Contributor Terms are a replacement for the former CC-BY-SA license
all contributors granted (to everyone directly). Nowadays OSMF
"collects" all these rights using a contract called Contributor Terms.

>- Seems to have been written by an eminent, but small set of
>contributors (history
>
> 
>)

Did you have a look at the mailing list archives of the time when this
policy was written (+-6 months)?

Both Import Guidelines and Automated Edits Code of Conduct are
guidelines which will reduce the likelihood that your import/mechanical
edit gets reverted.

We don't have a Don't Delete Everything Policy. Nevertheless, we revert
vandalism (if we discover it).

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Need to revert a bunch of changesets

[Michael Reichert]

Hi Robert,

Am 26.06.2016 um 06:10 schrieb Robert Helvie:
> I don't know about any other edits the user has made, but the ones in the
> Sejong area really should be reverted. It is a shame, because the other
> data they add such as names and address info could be very useful. But
> their copying of possibly unlicensed data without attribution puts
> Openstreetmap in jeopardy.

What's the nickname of the user you are complaining about?
Which changesets of this user have been commented by you?

If you think that a revert is the best solution, you should avoid manual
fixes. They generate conflicts during the reverts. I hope that your
fixes do not contain "valueable" information (i.e. can be also reverted
without loosing good information).

If the user continues adding fictional data or copies from other sources
without permission although you have wrote that to him twice or more
often, you can ask DWG to block him temporarily. This will either stop
him adding new data or – what I hope – read your comments and change his
behaviour.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to handle Maps.Me garbage?

[Michael Reichert]

Hi Martin,

Am 22.06.2016 um 15:04 schrieb Martin Koppenhoefer:
> I would add fixme tags and decide on an individual basis how to deal with
> it. Still, despite all lamentation, I admit that the amount of surveyed
> addressing information we are getting this way is great (precision to be
> confirmed).

If someone wants to import some low-/mixed quality stuff into OSM and
suggest to add fixme=* to lots of objects, we usually refuse to give the
import "permission" because such data usually will not be fixed. That's
why I think that just reverting is the best solution.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to handle Maps.Me garbage?

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Joost,

Am 22.06.2016 um 15:09 schrieb joost schouppe:
> Did you miss the ongoing thread on this subject? [1]

If read the thread but was not able to draw a conclusion regarding my
question.

> You should of course contact the mapper with the explanation that
> name is for local names. Though as mentioned in the other thread,
> maps.me seems to be working on a way to handle this situation
> better.

I decided not to write a changeset comment because it seems to me to
be a waste of time to comment a Maps.Me user's changeset. (There less
frequently respond to comments than iD users)

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)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXao8JAAoJEB87G9rMCMyIk5QP/39986/x9SUS0MZNv0TBh32L
3h0fu4RVSFslBgc2lJYGBnhMMpixMIZhAU9k2lpZlXUj6SFZh4veeAGo2wla6Sqx
7oUI8IaK2Iz639gGWpL2Rpt/3UDpeGyC0SvkpN2lnK/ycu1LsCarBTFB6UnfJOW6
5ur3PrPK230RucFg5bsDJ3zQiPdcVaeWj4mvjH7Nk/gXQWlpirkQOwQ3PFMGi+rd
vWaYIAt3497vuOIq+0eapbOnfvxzlbXsSNF2IEG0gzl9fY1XdU49q1baDTIW9o/y
iqINXZqlplMRMticqybCXSyZQYPFyr6eVqP9J2tlh+DCylzkISKnL+91bogNWWA3
Fk2K4ldW14DkzJrAKJeKpBDsfb8JYkZhcWt344Lc9gZZxHX0iqJY43AjDN39HOps
QeeABXAF488IhXQZzf9hqTuGOJe5YPfLCBj3r54c7Y+ilzpM9JLGoHr/zCQGfwUA
6AtQ1g6vNVYY+SPUtMLWXkwDtFVFkGql3MIfiYiLdsz0yDYM4zz9hevv+KtRRwdt
eX8SJI1q8dIHop+rk5uk/jmiwQhtRHYAIGw6IowWxyNyFRWg4TIr/PM4vCXAwj9j
QZJH/B5IlFc+dJZXpJJWTAcv7WDyAcH/17N9//RV0QuXslJcNQB7SksbrqgptrcH
WfKZqZ+ivAtyPL3gcern
=4uVS
-END PGP SIGNATURE-

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

[OSM-talk] How to handle Maps.Me garbage?

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

by browsing the map, I have discovered the edits of user 이진영
(Google Translator says that this is a Korean name). He added some
POIs in serveral European countries and entered the Korean name into
name=*.

https://www.openstreetmap.org/user/%EC%9D%B4%EC%A7%84%EC%98%81/history

Shall I either revert his changesets in total or shall I change
(mechanically/without local knowledge) name=* to name:ko=*?

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)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXaoPZAAoJEB87G9rMCMyILLAQAKcvg3GQOP2SLq0yD3SyFV57
V1+jtTzkVCSjE7bjtaAZZPcQ4FS5BV4FX2uEXVKoXAuNyLi4x8lPf+VnKeJaXJtz
CATOP+ihQcRHO9noEZdzyaL0Licp0NbqtZ0uYkuocZYu+r7ZN7lykz8waXXJibZ7
TTxx54mcQIvd6QY+d87B8x2mGug7ZxGItgmTZ2vmYkjkIgC1FB7HAAvxyECKExop
Q/d1AwVQw9356QzrbvvCobDD5kBrYhPxsAyscmZ8wGm5r8Dt+TFUoqARYNJqn7V3
28Aq11dcARNwCBu82ORobhhx8D/g0vXyoqicW3OcXU5FkGc2TGtqwZPSoVz+qhdM
JUxRXLJPIh9oub/7fTNZMFaR3NSMLmmM6eTgdJd3RHzRhk8h0S7fxOnw6JKmLjLF
7kG390VCi6qL+ndVEjSQENzJMegmg5vZuOcbYP/vyHlaeg7U7gZvp7dNeWSUERar
eUJsoQioTaQpeHuZVE1g3JNnoDqSDzWf6isIHsqs9xDVLRd2FFiZmqPkAp/iTw5/
gLKuB5IzwS5QANwsBIYBWFwAZAkb/PNl1ghl/HTsZ3W6FNGlbByZ7HRwe+Jpr+hS
8eza0DcFlySX+0rPh/fqrud/0nlDxM5/sOJS2lDo/nfs4kwxiQoUW9Zvqh52YHKI
6t4POZiGZE9cSYBzE00v
=qnGT
-END PGP SIGNATURE-

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Martin,

Am 17.06.2016 um 17:52 schrieb Martin Koppenhoefer:
> Apparently Maps.me, the most popular open map app for mobile, has
> gained some editing functions recently. While this is great news
> (millions of new mappers), it also bears some potential for
> trouble, as these new mappers often don't seem to be familiar with
> OSM tagging.
> 
> In the past weeks there have been several complaints on the Italian
> mailing list (leading to reverts), and I am sure, elsewhere you
> will find similar issues.
> 
> One example: https://www.openstreetmap.org/changeset/40094970
> 
> The mapper added chinese names right into the name tag, but as this
> is a place in Italy, these should rather be in Italian.

There is also a discussion about Maps.Me edits at German forum [1] and
an (English) wiki page [2] collecting problems/problematic edits of
Maps.Me users.

Best regards

Michael


[1] http://forum.openstreetmap.org/viewtopic.php?id=54874
[2] https://wiki.openstreetmap.org/wiki/Maps.Me/Questionable_OSM_Edits

- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXZDZKAAoJEB87G9rMCMyIaX0QAMfJc6BbOadUbDk/rZH6Sr36
oO28RTEHQPNuWHiAMxYnzPBfjw5XjtgSpi26b9pvrmnYwF7oV6x5rn2Nec3WMgLq
EoueZ3OSv8olD71ZuqpE1gqD2SLIQYByX5HbmgtgnuCGu7xBpelx1yhGEVU8sx65
sb3ppYQlbbekax7XDsfTlDTgJEZKm/NvI4k9b/U8yw98jOFl99AURnHBq+48Yn/P
hL8//kvCN1gbffnS4zYSf5iSDdTKncj4cpY0SGU97wnNjyhMTJYRX8xYH8WsEb8c
Ot6q6nb3x+zVtukRUuo38NdhBurt5K0LnBIoLU8BTUpGblPkNyfk16rO74TNvGRv
197z6bURia+QNkNR0cWUdDdRWAw6pxAmh9eQ7pkXoqdOV6FxfdXdrEZPLH4e+38O
LopOmxHVm7YBh4lh7iUjalFWQwgDlLRrezdt0hcRL4UDTmJXrP+tIw+oDG3gf0sd
eQVVASv/+LAW7X8Hq8ThAJzH4qh0w0BFWulEFmIW2j7OqdkhQyKfOFEOoALpEOvO
BbbxVrAzrovsmkXU6IIJCBwQMDZhMr3xkiPP/HcKEF3CzY21d3JG5drHnKXm5yUv
22M9U02NnwkrkCCgLnTDc2jQhLdOcRJa7MaplOogQwbZCPJSjlnFewcJwGYWOibF
LrZyDdOa+hAcU14KbtAs
=UH7F
-END PGP SIGNATURE-

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

Re: [OSM-talk] iD news: v1.9.6 released

[Michael Reichert]

Hi Bryan,

Am 08.06.2016 um 17:59 schrieb Bryan Housel:
> - When setting Wikipedia field value, also set corresponding Wikidata tag 
> (worked on by Minh Nguyễn)

Isn't this a kind of mechanical edit which should be discussed on this
mailing list *beforehand*?

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

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)




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] RfD notification: Purge tag "priority" from tracks

[Michael Reichert]

Hi Greg,

Am 09.04.2016 um 18:52 schrieb Greg Morgan:
> Thank you for publishing your intent.  I am coping the US Talk list because
> a number of us rail fans in the US are looking at European tag models for
> the vast railway network that we are piecing together.
> http://www.openrailwaymap.org/ looks like the only way to show cases all
> the features of rail changes. Will there be an impact to the railway map
> too?

OpenRailwayMap has never supported priority=*. It was Mentz who found
this tag at an old, abandoned proposal although some railway mappers had
told them that there is a better tagging (usage=* + service=*). There
are already validation rules for JOSM users which show warnings if a
track has priority=*.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] Slack

[Michael Reichert]

Hi Dave,

Am 29.03.2016 um 22:45 schrieb Dave F:
> Because IRC works in real time. Contributors have to be in the same time
> zone (or stay up really late/ get up really early). It's biased towards
> densely populated zones ie Northern Europe or East coast if North America.

You will face this problem with every type of communication, even email.
You will have a slower conversation if the other contributors live 9
hours off your local time.

> As it has no record facility it turns into the equivalent of little
> groups huddling away secretively in the corner of the room to have a
> whispered conversation; something that only teenage girls usually do.

Do really want to read the full log of a chat room? Do you yourself
really do that? Reading the archive of a mailing list gets
time-consuming if there are many postings. But you have email subjects
and threading at a mailing list archive which is not available at a
Slack/IRC/XMPP channel. Note that people write emails slower than a chat
messages and therefore the text is well thought out (I hope, sometimes
this is not true) and therefore easier to read.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] Slack

[Michael Reichert]

Hi Martijn,

Am 29.03.2016 um 21:52 schrieb Martijn van Exel:
> I find this a really worthwhile conversation to have. IRC is still great for 
> some but it’s hardly inclusive.

Is http://irc.openstreetmap.org/ no web interface? I might lack some
advertisment (and maybe an modern styling). If you just want to have an
open multi use chat, IRC offers everything you need.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] who do we trust for photos?

[Michael Reichert]

Hi Russ,

Am 13.02.2016 um 22:24 schrieb Russ Nelson:
> Here's a possibly silly, possibly serious question: who do we trust to
> keep photos of features? Once I finish gathering my set of photos of
> NY railroad bridges, where should I upload them so that I can
> automagically add links to the photos to each OSM bridge=yes way?
> 
> Flickr? Archive.org? Wikimedia.org? Google Photos? Instagram?

Do you speak of adding a image=$URL tag to these bridges? (Btw, I would
add a man_made=bridge polygon if you have good aerial imagery and add
the image=* tag to this polygon)

image=* should – from my point of view – only used for images which have
been published under a free and open license and whose platform can
easily queried for the image's license by data users.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Georeferencing lots of photos using JOSM

[Michael Reichert]

Hi Russ,

Am 13.02.2016 um 21:41 schrieb Russ Nelson:
> Solution: I remember where I took every photo (but if I see you
> walking on the street I won't remember your name; go figure), so it's
> just a matter of getting a lat/lon and storing it with every
> photo. So, I look at the photo, and use JOSM to visit that location. I
> add a node at the location I took a photo, use Ctrl-Alt-C to copy the
> lat/lon, then Ctrl-Z to remove the node. Then I copy the lat/lon into
> a shell command called "setgps" (included below), which takes three
> parameters: lat, long, and the photo. It uses exiftool to stuff the
> lat/lon and hemisphere into the photo.

There is a JOSM plugin which fetches coordinates from a GPX waypoint
which has the same name as the photo. I haven't tried it yet because
there was no need to try it.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: OpenStreetMap Wiki page Map Features has been changed by David1234

[Michael Reichert]

Hi Colin,

Am 2015-12-26 um 11:41 schrieb Colin Smale:
> Anyone know what is going on here? A newly registered user has removed
> all the content from an important wiki page (Map Features) and replaced
> it with a test message...

I reverted his changes at Map_Features and will have a look at his other
changes if there are any.

Btw, why didn't you revert the changes on your own? :-) It is very easy
(compared to reverting at OSM).

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Community Conference

[Michael Reichert]

Hi Steve,

Am 2015-12-02 um 22:23 schrieb Steve Coast:
> I’ve heard from a few people thinking of organizing an OpenStreetMap 
> conference focused on the community, very different from what SOTM has become.

I have counted 20 talks by companies and universities out of 40 talks at
all at SotM 2014. (You can argue if HOT is a company or not ;-) )
https://wiki.openstreetmap.org/wiki/State_Of_The_Map_2014

There were 19 talks by larger companies at SotM-EU 2014 (Small companies
like Omniscale have not been counted as companies). There were 39 talks
in total. http://www.sotm-eu.org/en/program

Conclusion: Both conferences had almost the same ratio of commercial and
community talks.

Maybe the SotM-EU had a more community-like image because lots of the
"commercial talks" were also topics the community is interested in. I
doubt if talks like this "OSM on Wheels" are very interesting.
https://wiki.openstreetmap.org/wiki/SotM_2014_session:_OSM_on_wheels
I filmed the German version at FOSSGIS 2015 and I found it – sorry – boring.

A conference can become a real community conference if it is located at
the center of the community, i.e. in Europe. Having a conference at a
remote location, i.e. Buenos Aires, might be good to boost the local
communities but it is not profitable.

I think that organizing a second conference which just tries to be a
competitor of SotM is a waste of time and workforce. Every conference
needs to be organized (venue, catering, program committee, website,
registration etc.). Having a second conference just takes power away
from the volunteers organizing SotM. (I do not want to say that regional
conferences like SotM Scotland or SotM-EU or FOSSGIS Conference are a
wast of time – I myself helped at two of these conferences)

If the focus of SotM is wrong, it should be changed. It is the power of
the program committee which decides which talks will be held. It would
be better to join SotM Working Group and/or program committee to make
things change. Maybe there are too much company employees member of the
program committee?

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What3words

[Michael Reichert]

Hi Colin,

Am 2015-11-22 um 11:39 schrieb Colin Smale:
> I have heard a few times recently about what3words, a new novel
> coordinate/addressing system for the whole world. 
> 
> Could/should we be doing anything to support/facilitate/implement this
> system in OSM? 

No. It is a propietary system and there is no place for such stuff at OSM.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] A message to our friends at HOT, Peace Corps etc. about Changeset Comments

[Michael Reichert]

Hi,



Am 19. November 2015 01:52:40 MEZ, schrieb john whelan :
> HOT and OSM are slightly different, HOT maps on OSM but uses a simpler
> more
> standardized approach.  

HOT uses the OSM database/platform and therefore it has to adapt and follow 
OSM's rules. Nobody forces you to use OSM. Why don't you do something like 
OpenHistoricalMap and use your own database basrd on OSM software?

> HOT tends to map in areas that do not have a great deal of OSM mapping
> already in place so I don't see that it really matters if they use
> preset
> comments from the tile system.  The HOT comment gives you the task and
> tile
> number so you can look up on the tile system where it is and also what
> has
> been asked for.

A mapper should be able to get an idea what has been edited at a given 
changeset without decrypting the changeset comment using an external service 
(HOT tasking manager in this case). Who guarantees that HOT tasking manager 
will still be online in 5 or 10 years?

Best regards

Michael
-- 
Diese Nachricht wurde auf einem Smartphone verfasst, ist daher nicht 
GPG-signiert und enthält Tippfejler.
This message was been written on a smartphone. That's why it is not GPG-signed 
and may contain tyops.

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

Re: [OSM-talk] Improved new Icon set for Open Street map

[Michael Reichert]

Hi Nasir,

Am 2015-11-02 um 17:53 schrieb Nasir Khan:
> One thing i faced every time and asked from many that, is there a way to
> improve the icon set to make the map more attractive. I really feel that we
> all should look at this issue and make a plan to improve this user
> experience. If you compare the OSM with the Google map icons, then you can
> say that the Google Map is way more ahead that the OSM.
> 
> I am not sure if it is right forum to discuss this issue. Please help me if
> i posted in the wrong mailing list. 

Well, your choice of the mailing list is ok. ;-)

The map style used for the map at osm.org is called OSM Carto and
developed at Github.

https://github.com/gravitystorm/openstreetmap-carto

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Become an OSMF member without Paypal?

[Michael Reichert]

Hi,

I would like to become an OSMF normal member to be entitle to vote at
the next AGM but I have a problem regarding the first payment of the
membership fee.

How can I become an OSMF normal member by paying the fee via bank
transfer instead of PayPal? [1] The signup page
(https://join.osmfoundation.org/normal-membership/) says at the bottom:
> You will be asked to transfer the membership fee via Paypal. Is
> Paypal not an option for you? Please go to our page regarding
> [alternative payment options](https://join.osmfoundation.org
> /alternative-payment-options).

If I continue with the signup form, I'll get to an PayPal page asking
for my PayPal account (or credit cad instead) which is ok if I would
want to pay via Paypal.

Now my question: How does my membership information (name, address etc.)
come to OSMF if I pay via bank transfer? I have seen a form which asks
for name and email address if I just want to pay my annual membership
fee.
https://docs.google.com/forms/d/1FBUgLFEJsuDigHEuZ5jdsQvk6ajPjzKWAQd-hPvOVwE/viewform

Shall I send my subscription request via email because there is no
PayPal-free signup form on the web?!

From my point of view this is an usability hurdle at the signup process
and should be improved. Currently it is not clear to people like how to
become a member without an PayPal account.

I ask this question at Talk mailing list because I want the answer to be
public and because I have not subscribed OSMF-Talk yet.

Best regards

Michael
who does not buy at online shos which only offer PayPal as payment options



[1] I refuse to use PayPal because I avoid this company.

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] User WJtW - railway track counts

[Michael Reichert]

Hi Paul,

Am 2015-10-16 um 22:58 schrieb Paul Johnson:
> Not even sure how passenger_lines=* is even a tag given route=rail
> relations...

As far as I know, passenger_lines=* is intended as an tracks=*
replacement if each track is mapped. There is an ITO map which renders
passenger_lines=*. There has also been a map for tracks=* but I have ask
ITO to shut it down because of wrong usage of the tracks=* key as WJtW did.

http://www.itoworld.com/map/231

I myself think that we do not need a passenger_lines=* tag and I do not
care about this tag. I think that such a information (number of parallel
tracks) might be extracted from existing OSM tracks without an
additional key. passenger_lines=* is fragile because not all users know
of its existence if they add a new built track.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] User WJtW - railway track counts

[Michael Reichert]

Hi Colin,

Am 2015-10-10 um 14:07 schrieb Colin Smale:
> Oh by the way, user WJtW is still at it, most recently in Italy, filling
> in loads of detail tags on railways. No idea where the information comes
> from. But every segment he touches has tracks=N added, often with N>1 on
> routes already mapped with individual tracks. 
> 
> @Michael Reichart, did you get a response from DWG about a possible
> block on this user? 

DWG waited until he restarted editing (he took a break of three days)
but now he has been blocked.

https://www.openstreetmap.org/user_blocks/819

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] User WJtW - railway track counts

[Michael Reichert]

Hi,

Am 2015-10-07 um 10:24 schrieb Richard Mann:
> Putting tracks=1 on multiple parallel tracks is also potentially
> misleading. It's a method of tagging that's been superseded by drawing each
> line separately.
> 
> So I took to adding passenger_lines=N, to avoid a compatability conflict. I
> only did N=1 or N>=4, though.
> 
> I'd suggest converting the tagging to tracks=1+passenger_lines=2.

You can find the tag detail=track on lots of tracks in South-West
Germany instead of tracks=1.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] User WJtW - railway track counts

[Michael Reichert]

Hi.

Am 2015-10-07 um 10:03 schrieb Colin Smale:
> I am not sure it would be vandalism - It is more likely a
> misunderstanding of the intention of the tracks=* tag. But it is very
> damaging, and potentially hard to revert as this has been going on for
> some time and newer edits may have been made. It may need something like
> this: 
> 
>   * Get all changesets from WJtW
>   * get all railway tracks from those changesets with tracks>1
>   * search back through the history to find where the tag was added
>   * see if it was user WJtW that did it
>   * If so, remove the tracks=* tag.

I (a German railway mapper) have been notified by another user about
WJtW's edits last week. I [1] have already started reverting parts of
his edits. That's the way I did it:

- Search for railway=rail + tracks=2 via Overpass Turbo (with meta as
output variant)
- Pick out one way of the result. If its last edited was done by WJtW, I
had a lookat the changeset which did this edit using Achavi. If the
changeset was mostly adding of tracks=2, I reverted it. Sometimes I did
partial reverts if only parts of the changeset were bad.
- If the last edit of the way was done by another user, I had a look
into the way's history and looked for the bad changeset(s) there.

You have to repeat this until the area which you are going to clean is
free of tracks=2.

Note: If you are looking at the area between Dortmund and Cologne –
there are lots of ways with tracks=2 from old times (about 4 to 7 years
ago) because tracks=2 has not been removed when the second track was
added to OSM.

> But in Dutch (as you will know) there is a wonderful expression about
> trying to mop up (a flooded bathroom) while the tap is still running. We
> need to turn the tap off and stop this getting any worse. 
> 
> It's starting to sound like a candidate for a user block until the user
> engages in some kind of dialog. 

I have asked DWG to block him (0-hour-block) because he has been
notified about his errors several times:

https://www.openstreetmap.org/changeset/34049497 (21 days ago in German)
https://www.openstreetmap.org/changeset/34264606 (11 days ago in English)
http://www.openstreetmap.org/changeset/34313237 (7 days ago in English)

It is not the first time that a user used tracks=2 the wrong way. There
were/are users from time to time who add tracks=2 because there was a
map by ITO rendering tracks=2. I asked the people from ITO to shut down
this map a few days ago to prevent future abuse of tracks=2 as tagging
for the renderer. I thank ITO for their quick reaction (the took the map
offline). http://www.itoworld.com/map/group/1

Best regards

Michael aka Nakaner


[1] via my cleanup account Nakaner-repair


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Previous planet dump sizes

[Michael Reichert]

Hi Stephen,

Am 2015-09-22 um 20:29 schrieb Stephen Knox:
> Is there a log or archive of these files anywhere? I would like to plot the
> growth of open street map data by time, ideally but not necessarily by
> region. So I am interested in the file size rather than the file itself.

You can even get planet files – back until the first ODbL planet on
2012-09-12.

http://planet.openstreetmap.org/planet/

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Motion: Dedicated mailing list for abandoned railways

[Michael Reichert]

Hi Jukka,

Am 2015-09-09 um 09:48 schrieb Jukka Rahkonen:
> I suggest to make a new mailing list for those who want to talk about
> abandoned railways. I can see that such does not exist yet
> https://lists.openstreetmap.org/listinfo. It has already suggested to use
> the Historic list https://lists.openstreetmap.org/pipermail/historic/ but I
> have understood that abandoned railways are special and therefore they
> deserve a dedicated list.

I do not think that we need a dedicated mailing list just for abandoned
railway lines. There are already two mailing list in this field and you
can choose where you want to discuss something.

OpenRailwayMap mailing list
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
also available via NNTP via Gmane:
gmane.comp.gis.openstreetmap.openrailwaymap
Due to the concentration of detailed railway mapping in Germany, it is a
German and English mailing list. And you may read a lot about details of
German railway signalling and German railway operating rules/laws.

Historical mailing list
https://lists.openstreetmap.org/listinfo/historic
also available via NNTP via Gmane:
gmane.comp.gis.openstreetmap.historic

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mechanical edits

[Michael Reichert]

Hi Andrew,

Am 2015-06-29 um 17:01 schrieb Andrew MacKinnon:
> I admit that I have been guilty of doing inappropriate mechanical
> edits in the past, but I am wondering: is it time that OSM implements
> controls on doing mechanical edits in the API? In other words, should
> OSM implement a feature in the API that bans doing edits over a
> certain size (perhaps 5 degrees latitude or 5 degrees longitude, with
> larger amounts of longitude allowed near the north and south pole as
> this would make editing there impossible otherwise), with exceptions
> for administrators/designated users? Would this cause so much of a
> problem for legitimate users that this is a bad idea?

A large bounding box of a changeset is not a proof that the edit is
mechanical. There are also users at OSM who first edit an object in
Europe and afterwards in America before they upload their changes. (This
usually happens if the user uses JOSM oder Potlatch 2) On the other
hand, it is possible that a users who performs a mechanical edit uploads
his changes in small chunks, each having a small bounding box (few
square kilometers).

Adding such a feature just increase the amount of work of a group of
"administrators". Every user who wants to legallay perform a mechanical
edit has to get additional rights granted.

That's why I think that there should be no restriction on API side.
Either people realize that mechanical edits have to be disussed first
(after revert of their first undiscussed mechanical edit) or they get
blocked if they refuse contact with the community.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Routing Applications

[Michael Reichert]

Hi,

Am 2015-06-17 um 05:33 schrieb Hans De Kryger:
> Why do OSRM & OpenRoutingService compete against each other instead of
> joining resources and combining efforts to make the best routing service
> out there? Am i missing something?

There are differences in history between these two projects. ORS
(OpenRouteService) is a project started by University of Heidelberg as a
closed-source project in 2010 (?). It was dead between 2012 and 2014,
i.e. no data update, no bugfixing because it is a university project.

Open Source Routing Machine (OSRM) was started by Dennis Luxen who
gained a PhD at Karlsruhe Institute of Technology. Afterwards he worked
for Mapbox which now contributes much to OSRM.

Summarized: OSRM is a commercial open source project and ORS is a
university project.

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Routing Applications

[Michael Reichert]

Hi,

Am 2015-06-17 um 14:38 schrieb Eugene Alvin Villar:
> This has been fixed in Osmand early this year after being reported
> more than 2 years ago. Unfortunately, multiple via ways are still not
> supported.

I wonder if a via way instead of an via node is necessary so much. I
wonder more where someone /really/ needs multiple via ways. Can you call
examples for multiple via ways (link to relation)?

Best regard

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk