Re: [OSM-talk-fr] OpenStreetMap dans « Libre à vous ! » - demain mardi 11 juin sur radio Cause Commune

[Jean-Christophe Becquet]

Le 11/06/2019 21:30, osm.sanspourr...@spamgourmet.com a écrit :
> Il y a mensonge sur le programme ou la rediffusion n'est pas le même jour ?
> 
> Je lis "Et l'émission sera rediffusée le soir même de 21 h à 22 h 30."
> mais ce n'est point ce que j'entends.

Bonjour,

L'émission est rediffusée le soir même, sauf contretemps. Ce qui est
arrivé ce mardi, désolé.

Le podcast est à présent disponible sous licence libre sur le site de
l'April :
https://media.april.org/audio/radio-cause-commune/libre-a-vous/emissions/20190611/libre-a-vous-20190611-openstreetmap-state-of-the-map-france-christian-quest-jean-christophe-becquet-noemie-lehuby.ogg

La page consacrée à l'émission sur le site web de l'April avec les
références :
https://www.april.org/libre-a-vous-diffusee-mardi-11-juin-2019-sur-radio-cause-commune-documentaire-sur-le-logiciel-libre


PS : la bise aux amis contributeurs qui sont à Montpellier pour le SotM.
Désolé, je ne peux pas être présent cette année.

Bon week-end

JCB
-- 
Digne : SIG libres à l'IUT avec les étudiants - mercredi 19 juin
https://iut.univ-amu.fr/presentation-logiciels-libres-sig-19-juin-2019

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===



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

Re: [Talk-at] Schule für Shiatsu

[Stefan Tauner via Talk-at]

On Fri, 14 Jun 2019 09:19:10 +0200
Christian Aigner  wrote:

> Werte Kolleginnen und Kollegen!
> 
> Ich bin gerade dabei, eine Schule für Shiatsu-Ausbildung einzutragen.
> 
> Was nehme ich da am besten?
> 
> amenity=school
> 
> oder die Kombination
> 
> amenity=education
> education=shiatsu
> 
> Oder gar etwas anderes? Wie würdet ihr das eintragen?

Wenn ich mir kurz die Wikipedia-Seite zu shiatsu ansehe, dann würde ich
eher irgendetwas mit Religion vorschlagen... ;) Ernsthaft: ich würd's
einfach nicht eintragen, jedenfalls nicht als amenity=school weil das
überhaupt nicht zu dessen Definition passt und =education is depricated.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

[OSM-ja] 7/7 京都！街歩き！マッピングパーティ：第10回 清凉寺

[yasunari yamashita]

山下です。皆さんこんにちわ。

7月の京都！街歩き！マッピングパーティは、七夕様の7日に
光源氏が造営した「嵯峨の御堂」に目される寺院
清凉寺（嵯峨釈迦堂）をターゲットに開催します。
https://openstreetmap-kyoto.connpass.com/event/135595/

いつでも行ける嵯峨釈迦堂、なのに何か機会でもないと、
なかなか訪れることがありません（京都あるある）。
私も二年ぶりぐらいでしょうか。。。

いつでも行ける 京都！街歩き！マッピングパーティ
皆様の参加をお待ちしています！
-- 
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-at] Sammelrelationen XX in YY

[Friedrich Volkmann]

On 15.06.19 00:52, Robert Grübler wrote:

Generell ist es ja mit Relationen sind keine Kategorien 
(https://wiki.openstreetmap.org/wiki/DE:Relationen/Relationen_sind_keine_Kategorien
 ) beantwortet.


Das ist derselbe Link, den ich schon im ersten Beitrag gepostet habe, nur 
diesmal in der deutschen Übersetzung.



Im Einzelfall kann die Abgrenzung nicht so einfach sein. Siehe z.B. diese 
Diskussion hier https://wiki.openstreetmap.org/wiki/Talk:Relation:network über 
Knotenpunktnetzwerke.


Was meinst du mit Knotenpunktnetzwerken, und wie unterscheiden die sich von 
Knotennetzwerken und von Punktnetzwerken? Auf jener Seite ist von "junction 
node networks" die Rede, das würde ich eher als Kreuzungsnode-Netzwerke 
übersetzen. Weiter unten geht es dann aber um Fahrradrouten, was mit 
Kreuzungen überhaupt nichts zu tun hat. In meinen Augen ist das, was dieser 
U30303020 dort zusammengeschrieben hat, lauter wirres Zeug, und das ist der 
Grund, warum ihm noch keiner geantwortet hat.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-at] Sammelrelationen XX in YY

[Robert Grübler]

Friedrich Volkmann schrieb am Freitag, 14. Juni 2019 21:15:

> Das sind teils uralte Relationen mit unzähligen Bearbeitern. 
> Mir geht es jetzt erst mal um eine Grundsatzdiskussion, 
> also ob wir solche Relationen grundsätzlich haben wollen. 
> Erst wenn wir zu einem Konsens kommen, dass wir sie nicht wollen, 
> zahlt sich überhaupt der Aufwand aus, eine Liste der betroffenen 
> Relationen zu erstellen und die Bearbeiter zu kontaktieren.

Generell ist es ja mit Relationen sind keine Kategorien 
(https://wiki.openstreetmap.org/wiki/DE:Relationen/Relationen_sind_keine_Kategorien
 ) beantwortet. Im Einzelfall kann die Abgrenzung nicht so einfach sein. Siehe 
z.B. diese Diskussion hier 
https://wiki.openstreetmap.org/wiki/Talk:Relation:network über 
Knotenpunktnetzwerke.

LG Robert


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

Re: [Talk-GB] GPS devices

[James Harrison]

On 14/06/2019 20:56, Simon Ritchie wrote:
> 
> I'm currently evaluating the Emlid Reach M+ device.  It's a lovely
> little thing, powered through the USB so can be run using a mobile phone
> power bank.  It has Bluetooth and uses your laptop or smartphone as a
> display and Internet connection.  So far I can make it accurate to about
> half a metre.

We've been trialling the RS+ devices and with two you can get
sub-decimetre faiiirly reliably (either using LoRa radios or IP
correction services). Their RS2 looks much improved, though, so I've got
a few on order. Bit pricier than the M+/RS+, but a proper "survey spec"
receiver.

-- 
Cheers,
James Harrison



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

Re: [Talk-us] Need someone in the south to review an edit

[Rihards]

On 14.06.19 17:59, Micah Cochran wrote:
> 
> One of the following changeset comments suggests the deletions in this
> changeset are to remove duplicates added by mistake previously.
> 
> 
> I checked the a few local locations of the business (Athens, Alabama). 
> There are still nodes/ways for the "Express Oil Change" locations, which
> would seem to suggest that it was just correcting duplicates (as Shawn
> pointed out).  

I zoomed in on one location, and the node was, judging by the imagery,
on a street (literally). I hope Brandify does not set locations from
Google address searches.

> The business is still in business, I think I drove by one this week.
> 
> Micah Cochran-- 
 Rihards

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

Re: [OSM-talk-fr] Osmose erreurs#1270

[ades]

faudrait d’abord demander aux Vénitiens comment ils appellent ça ;-)

Je ne taguerai pas ça comme quai, où sont les éléments constitutifs d’un quai : 
anneaux, bites, etc. ? Et je pense que même si ça peut servir de point 
d’embarquement ce n’est pas un quai.

Là on a juste la fin d’une rue. Que ce soit un mur ou un canal qui termine la 
rue, c’est la même chose, la rue s’arrête là, point… c’est une impasse.


> Le 14 juin 2019 à 21:40, osm.sanspourr...@spamgourmet.com a écrit :
> 
> Vu l'usage et l'absence de parapet/barrière je n'hésiterais pas : c'est un 
> quai.
> 
> C'est fait pour servir de quai et non pour éviter que la rue ne tombe ^^
> 
> Le 14/06/2019 à 09:58, marc marc - marc_marc_...@hotmail.com 
>  a écrit :
>> Le 14.06.19 à 08:39, lenny.libre a écrit :
>>> j'hésite encore entre le noexit et le "man_made=quay"
>>> https://goo.gl/maps/ezwLyzp122JTQD2U9 
>>> 
>> j'opterais pour un quai ou un mur de soutènement
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr 
>> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

[Talk-GB] GPS devices

[Simon Ritchie]

What GPS devices are people out there using, and how accurate are they?

I'm currently evaluating the Emlid Reach M+ device.  It's a lovely little
thing, powered through the USB so can be run using a mobile phone power
bank.  It has Bluetooth and uses your laptop or smartphone as a display and
Internet connection.  So far I can make it accurate to about half a metre.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Osmose erreurs#1270

[osm . sanspourriel]

Vu l'usage et l'absence de parapet/barrière je n'hésiterais pas : c'est
un quai.

C'est fait pour servir de quai et non pour éviter que la rue ne tombe ^^

Le 14/06/2019 à 09:58, marc marc - marc_marc_...@hotmail.com a écrit :

Le 14.06.19 à 08:39, lenny.libre a écrit :

j'hésite encore entre le noexit et le "man_made=quay"
https://goo.gl/maps/ezwLyzp122JTQD2U9

j'opterais pour un quai ou un mur de soutènement
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Sammelrelationen XX in YY

[Friedrich Volkmann]

On 14.06.19 19:04, Robert Grübler wrote:

@Friedrich

Hast du schon die Ersteller/Pfleger der Relationen angesprochen und ihre 
Argumente eingeholt?


Das sind teils uralte Relationen mit unzähligen Bearbeitern. Mir geht es 
jetzt erst mal um eine Grundsatzdiskussion, also ob wir solche Relationen 
grundsätzlich haben wollen. Erst wenn wir zu einem Konsens kommen, dass wir 
sie nicht wollen, zahlt sich überhaupt der Aufwand aus, eine Liste der 
betroffenen Relationen zu erstellen und die Bearbeiter zu kontaktieren.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Yves]

It isn't worth it, I'm afraid you're loosing your time. 
Given that the two tags aren't the same (amenity=atm is an atm, atm=yes 
contains an atm) you'll soon have this one art piece that definitely deserves 
amenity=atm + atm=no. Or not.
If you're not ready to consume OSM data using NOT, AND or OR, don't even start 
:)
Not to say that OSM should be a joyful mess, but to me such apparent redundancy 
does no harm. A matter of point of view on the best way to describe the same 
things, that's all. 
Yves 

Le 14 juin 2019 08:57:22 GMT+02:00, Mateusz Konieczny  
a écrit :
>Recently in mapping I encountered amenity=atm with atm=yes
>
>I manually removed atm=yes, but it turns that there is more of such
>objects.
>I propose to run an automatic edit that will remove atm=yes from all
>such objects.
>In addition I propose to remove also some other blatant and unnecessary
>duplicates.
>
>So in total I propose to remove
>
>atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
>
>transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
>
>sustenance=restaurant from amenity=restaurant
>http://overpass-turbo.eu/s/JWh
>sustenance=fast_food from amenity=fast_food
>http://overpass-turbo.eu/s/JWc
>service=post_office from amenity=post_office
>http://overpass-turbo.eu/s/JWa 
>
>as this duplicated tags are unnecessary, unwanted, confusing and
>undesirable.
>Edits would be split to not create overly large bounding boxes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] proposition tourism=camp_pitch

[Bibi via Talk-fr]

Bonjour, ça se passe par là :
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:tourism%3Dcamp_pitch#Voting

Bonjour,

comme les propositions complexes échouent, ici une proposition toute
simple : mettre les emplacements de camping sous la clé tourism comme ça
la clé camp_site peut restée utilisée proprement pour qualifier les
catégories de campings (basic, standard, serviced, deluxe).

Bon vote,

Jean-Yvon

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Mark Wagner]

On Fri, 14 Jun 2019 10:02:59 +0100
Dave F via talk  wrote:

> On 14/06/2019 07:57, Mateusz Konieczny wrote:
> > Edits would be split to not create overly large bounding boxes.  
> 
> As long as it's clearly commented, I wouldn't loose any sleep over
> the physical size of the changeset. OSM should be concerning itself
> with quality rather than quantity.
> 
> That the main website is antiquated & unable to display details of
> edits is not a reason to improve the database efficiently. Performing
> edits in one go makes them easier to keep track of & revert, if
> there's a problem.

It's not just the main website.  I'm not aware of any QA tool that
makes it easy to review a planet-spanning changeset.

-- 
Mark

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

Re: [Talk-at] Sammelrelationen XX in YY

[Robert Grübler]

@Friedrich

Hast du schon die Ersteller/Pfleger der Relationen angesprochen und ihre 
Argumente eingeholt?

 

@Norbert

Probier mal „Who’s around me  “ 
(http://resultmaps.neis-one.org/oooc)  für deine Gegend.

 

LG Robert

 

Von: norbert baldia [mailto:norbert.bal...@gmx.at] 
Gesendet: Freitag, 14. Juni 2019 09:33
An: talk-at@openstreetmap.org
Betreff: Re: [Talk-at] Sammelrelationen XX in YY

 

Lieber Friedrich!

 

Im Zusammenhang mit "Sammelrelation" - Wanderwege Türnitzer Alpen - würde ich 
gerne damit in Kontakt treten.

Ich suche schon lange einen OSM-Kollegen aus diesem Raum, der mir, einem eher 
ungeübten OSM-Beiträger, einige unterstützende praktische Anwendungen erklärt.

 

Mit kollegialen Beobachtergrüßen

 

aus dem (unrechten) Traisental

 

Norbert

Gesendet: Freitag, 14. Juni 2019 um 08:18 Uhr
Von: "Friedrich Volkmann" mailto:b...@volki.at> >
An: "OpenStreetMap AT" mailto:Talk-at@openstreetmap.org> >
Betreff: [Talk-at] Sammelrelationen XX in YY

Anlässlich der Relation 9463022 ("Wanderege Türnitzer Alpen") kommt mir vor,
dass diese Art von Relationen überhandnimmt. Im selben Editorfenster werden
mir zufällig auch eine Relation 7293702 "Landesstraßen B in
Niederösterreich" und 939634 "Österreichische Bundesstraßen" gelistet.
Letztere enthält ironischerweise nur solche Straßen, die dem Gesetz nach gar
keine Bundesstraßen mehr sind.

Ich bin dafür, alle derartigen Relationen zu löschen, erstens weil sie den
Regeln widersprechen
(https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories)
und zweitens weil sie die Wartbarkeit der anderen Relationen unnötigerweise
erschweren, indem die Relationenliste im Editor immer länger wird.

--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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

Re: [Talk-us] Need someone in the south to review an edit

[Andy Townsend]

On 14/06/2019 16:56, Paul Johnson wrote:
Aaah, OK.  Would have been nice if Brandify Tran replied to changeset 
comments.


With a DWG hat on I'll send them a "message that they have to read 
before continuing to edit" and ask them to check their registered email 
account.


Best Regards,

Andy




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

Re: [Talk-us] Need someone in the south to review an edit

[Paul Johnson]

Aaah, OK.  Would have been nice if Brandify Tran replied to changeset
comments.

On Fri, Jun 14, 2019, 10:01 Micah Cochran  wrote:

>
>> One of the following changeset comments suggests the deletions in this
>> changeset are to remove duplicates added by mistake previously.
>>
>>
> I checked the a few local locations of the business (Athens, Alabama).
> There are still nodes/ways for the "Express Oil Change" locations, which
> would seem to suggest that it was just correcting duplicates (as Shawn
> pointed out).
>
> The business is still in business, I think I drove by one this week.
>
> Micah Cochran
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Source dubbio

[Andrea Musuruane]

Hi Andy,

On Fri, Jun 7, 2019 at 10:56 PM Andy Townsend  wrote:

> Hello,
>
> Andy from the DWG here.  Apologies for the delay in getting around to this.
>
> (automatic translation into Italian below)
>
> Currently as I understand it:
>
>1. The licence under which this data was released isn't compatible
>with OSM
>2. The data quality isn't actually very good.
>
> With regard to (1) there is an option to try and obtain the data under a
> compatible licence.  However because of (2) we may not actually want to do
> that, and want to revert it anyway.
>
Exactly.

> If we do decide to revert it then we'll probably find that some data has
> been modified by other users since.  With this data we can again do one of
> two things:
>
>1. Leave it, because newer edits by other users may have corrected
>problems
>2. Force through the revert, which will undo good mapping by people
>unconnected with the import here.
>
> If the licence for the data isn't compatible then we'd normally tend to do
> (2) rather than (1) here.  Whichever we do there will be a lot of remapping
> to do and a lot of tidying up needed - afterwards I suspect that there will
> be things duplicated and things missing, however we do it.
>
It is my understanding local mappers waited for the revert. They didn't try
to correct issues or build upon these data.

> After we've finished any reversion we may then want to redact the data
> because it wasn't compatible with OSM in the first place.  If something is
> redacted the history will no longer be visible in OSM.  An example of what
> something looks like after it has been redacted is
> https://www.openstreetmap.org/way/325344168/history .
>
The redaction should be mandatory since these data aren't licensed under a
ODbL compatible license (and we have no waiver).

If we'll get a waiver in future, we'll propose a proper import (with proper
conflation!!!).

> Before starting on any of this, I just wanted to make sure that my
> understanding of the problem is correct:
>
>- The data to be reverted is all changesets by
>https://www.openstreetmap.org/user/fabioportinaro from
>https://www.openstreetmap.org/changeset/69299082 onwards
>- No other users have used the same data source directly
>- The community thinks that a revert is the best way forward
>
> That's correct.

>
>
> It would also be useful to know if anyone thinks that the data might be
> available under a licence other than CC-BY-4.0 which might be compatible
> with OSM.
>
CC-BY-4.0  is the license chosen by Regione Piemonte for all their open
data. So the data aren't available under another license.

Best regards,

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Jmapb]

On 6/14/2019 9:50 AM, Dave F via talk wrote:

On 14/06/2019 14:10, Jmapb wrote:

 If there's a problem with a well-thought-out mechanical edit, it's
highly likely to be localized,


For mechanical/bot/automated edits, errors are more likely to be
duplicated across all amendments.

If 'local mapping communities' have 'different ideas' it should be
queried as to what they are & why they're required.


Sure, when possible, but this is a belt-and-suspenders situation. The
automated edits code of conduct (
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Execute_with_caution
) is pretty clear about this:

- Execute only a small number of edits wait for feedback before
proceeding with larger edits.
- One changeset covering the whole planet is hard to read. Changes
grouped into small regions are easiest to digest for human mappers.

(paraphrased)

Jason


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

Re: [Talk-us] Need someone in the south to review an edit

[Micah Cochran]

>
>
> One of the following changeset comments suggests the deletions in this
> changeset are to remove duplicates added by mistake previously.
>
>
I checked the a few local locations of the business (Athens, Alabama).
There are still nodes/ways for the "Express Oil Change" locations, which
would seem to suggest that it was just correcting duplicates (as Shawn
pointed out).

The business is still in business, I think I drove by one this week.

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Mateusz Konieczny]

14 Jun 2019, 14:55 by dieterdre...@gmail.com:

> Looking at the actual sustenance values (total usage around 200 only), these 
> are all duplicating words which are already tagged as amenity values 
> (restaurant, fast_food etc.), I also haven't found specific documentation for 
> this key (and without a defined meaning it seems pointless to establish a 
> duplicate key here).
>
And it appears to be added solely by OsmAnd (I noticed it again during fixing
user_defined_other=* added by buggy/borken OsmAnd editor) 

> 2. service=post_office
> If the value for "service" is repeating "post office", it doesn't make sense, 
> but the basic idea of having a service tag for post offices does not seem 
> completely odd.
>
Yes, only service=post_office will be removed and only from amenity=post_office,
other service tags will be kept unchanged



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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Dave F via talk]

On 14/06/2019 14:10, Jmapb wrote:
 If there's a problem with a well-thought-out mechanical edit, it's 
highly likely to be localized,


For mechanical/bot/automated edits, errors are more likely to be 
duplicated across all amendments.


If 'local mapping communities' have 'different ideas' it should be 
queried as to what they are & why they're required.


DaveF



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

Re: [Talk-it] R: R: R: Casette captazione acqua

[Martin Koppenhoefer]

Am Do., 13. Juni 2019 um 20:10 Uhr schrieb angelo mornata <
angelo.morn...@hotmail.it>:

> Scusa Martin ma pensavo che la questione fosse chiusa, a questo punto è
> meglio spiegare quando vengono fatte e come, queste protezioni.
> Quando si decide che un a sorgente d'acqua può avere un interesse
> strategico per veicolare/captare l'acqua in un gruppo di
> /baite/case/villaggi/acquedotti ecc.. ecc... la prima cosa che si fa e'
> proteggerla da defecazioni animali o peggio ancora da animali morti che
> potrebbero decomporsi nelle fonte stessa, in pratinca si fanno 4 muri e un
> tetto in cemento che possono avere le seguenti dimensioni: altezza 1 mt.,
> profontità 1 mt., lunghezza 1mt, così come possono essere + grandi...
> Dentro queste protezioni c'è una vasca di sedimentazione (che intercetta
> eventuale sabbia), e un tubo posizionato più in alto del fondo della vasca
> che veicola l'acqua (capta) a baite/case/villaggi/acquedotti ecc..ecc...
> In lamiera non le ho mai viste.
> Quindi oltre "man_made=water_works" cosa dobbiamo mettere?
>



scusa Angelo, non volevo creare confusione. Penso che in realtà non esiste
un tag per questo tipo di strutture. Se si tratta di una centrale idrica,
il tag man_made=water_works è quello giusto, ma io con quel tag mi sarei
aspettato una struttura più grande, con personale in loco, ecc. qualcosa
così:
http://www.gulllakewater.com/wp-content/uploads/2010/04/insideplantnew9.gif
ma effetivamente la grandezza della struttura dipende dalla grandezza delle
comunità che deve essere servito.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Jmapb]

On 6/14/2019 5:02 AM, Dave F via talk wrote:


That the main website is antiquated & unable to display details of
edits is not a reason to improve the database efficiently. Performing
edits in one go makes them easier to keep track of & revert, if
there's a problem.

DaveF


IMO, smaller and more gradual mechanical edits are much easier to keep
track of & revert. If there's a problem with a well-thought-out
mechanical edit, it's highly likely to be localized, either a data edge
case or a local mapping community that has different ideas. Smaller
edits allow us take a look at the actual consequences and possibly
suggest changes. And smaller reverts are also easier for the software to
handle.

Jason


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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Martin Koppenhoefer]

Am Fr., 14. Juni 2019 um 09:00 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> So in total I propose to remove
>
> atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
> transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
> sustenance=restaurant from amenity=restaurant
> http://overpass-turbo.eu/s/JWh
> sustenance=fast_food from amenity=fast_food http://overpass-turbo.eu/s/JWc
> service=post_office from amenity=post_office
> http://overpass-turbo.eu/s/JWa
>
>


while it generally looks ok to do this automated removal, there could be
some point in

1.
sustenance=restaurant, although I would expect the restaurant-type to be
better fitting into a "restaurant" or "restaurant:type" tag.
I have so far been adding local restaurant (and fast food) types with the
key "restaurant:type:it", and this has become somehow common amongst
Italian mappers (not very common, currently 750 times applied), where
common values are ristorante, pizzeria, osteria, trattoria, rosticceria,
tavola calda, bar, enoteca, piadineria,...

Looking at the actual sustenance values (total usage around 200 only),
these are all duplicating words which are already tagged as amenity values
(restaurant, fast_food etc.), I also haven't found specific documentation
for this key (and without a defined meaning it seems pointless to establish
a duplicate key here).



2. service=post_office
It may not always be entirely clear these days what a post office is, while
say 30 years ago the answer to this question was quite simple in many
countries: the official, monopolized, state operated "official" post office.
What are the requirements, what is the definition? According to the wiki
[1], amenity=post_office is for "a post office" (and/or?) "a place where
letters and parcels may be sent or collected". This is very scarce. Is it
sufficient the place allows to collect letters and parcels? Is any place
where letters and parcels can be sent a "post office" (think messenger
services)? Why is there an "or" between "sent or collected", shouldn't that
be an "and"?
Commonly (quite country specific though), post offices may offer a lot more
services (offering post office boxes, sending / receiving money, selling
stamps, paying bills and taxes, identifying people, sending registered mail
and telegrams (yeah, these still exist), often post offices also act as a
bank, and they may also act as an insurance company, they may sell digital
signatures, etc. etc.). Ultimately the list of services would be very long
and repetitive if we tried to add all of them, but there could be a point
in listing postal services, financial services and banking, insurances.
If the value for "service" is repeating "post office", it doesn't make
sense, but the basic idea of having a service tag for post offices does not
seem completely odd.


Cheers,
Martin



[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpost_office
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] OS Open Greenspace tileset

[Robert Whittaker (OSM lists)]

On Fri, 14 Jun 2019 at 10:24, Richard Fairhurst  wrote:
> I've put together a simple tileset showing greenspace areas from Ordnance 
> Survey's recent OS Open Greenspace release. The data is released under the 
> standard OS open licence therefore suitable for tracing in OSM.
>
> Many features are already in OSM, but not all, and in addition the names 
> might be helpful.
>
> The tiles also include a few greenspace-related features from OSM and the 
> basic OSM road/path network.
>
> You can add the tiles to your favourite editor using this URL:
> http://osm.cycle.travel/greenspace/{z}/{x}/{y}.png

That's great -- many thanks Richard. A related existing service is
https://openover.raggedred.net/ , which shows OS Greenspace and also
Access Land polygons.

By the way, if anyone is in to tileservers for helping OSM, some tiles
with a rendering of OS Open Roads (with their names) would be really
useful I think:
https://www.ordnancesurvey.co.uk/business-and-government/products/os-open-roads.html
.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-pt] Relações em urbanização

[Nuno Caldeira]

vê este vídeo para acelerar o processo https://youtu.be/tELDooPvJ0s

não precisas adicionar relações. se o edifício tem uma só função, podes
deixar o polígono com a etiqueta da função. caso tenha mais que uma função,
deixas a etiqueta de edifício no polígono e adicionas o ponto da outra
função (loja, escritório, etc) dentro do edifício com o level a que esse
poi se encontra.

A sexta, 14/06/2019, 13:00,  escreveu:

> Send Talk-pt mailing list submissions to
> talk-pt@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-pt
> or, via email, send a message with subject or body 'help' to
> talk-pt-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-pt-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-pt digest..."
>
>
> Today's Topics:
>
>1. Re:  Estuário do Tejo & linha de costa (Topo Lusitania)
>   (Hugo Valentim)
>2. Relações em urbanização (Alexandre Badalo)
>
>
> --
>
> Message: 1
> Date: Thu, 13 Jun 2019 13:43:37 +
> From: Hugo Valentim 
> To: "talk-pt@openstreetmap.org" 
> Subject: Re: [Talk-pt]  Estuário do Tejo & linha de costa (Topo
> Lusitania)
> Message-ID:
> <
> lnxp265mb0153b438d675b137142aa7...@lnxp265mb0153.gbrp265.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> OK. Compreendi o histórico.
>
> A coastline, de facto, é renderizada a partir de informação tratada em
> separado (os shapefiles publicamente disponíveis são supostamente
> actualizados a cada 12 horas, não tenho a certeza se o openstreemap.org
> se actualiza com a mesma frequência…).
>
> Ora, do meu ponto de vista, no instante actual, a vantagem em usar a
> coastline para demarcar o Estuário reside precisamente no facto de ela não
> ser, do ponto de vista da edição do mapa, um polígono. O único requisito
> para não a “quebrar” é manter uma linha contínua de segmentos, um
> procedimento automático existe < https://osmcode.org/osmcoastline/> que
> se encarrega de gerar os polígonos de “água” com o devido limite de 2000
> pontos (em obediência à API v6) – por coincidência ou não gerando o
> mesmíssimo resultado do plugin Split do QGIS. Provavelmente os ficheiros <
> https://osmdata.openstreetmap.de/> também poderão ser usados na geração
> de mapas para Garmin.
>
> O uso da coastline também admite a renderização do natural=shoal (áreas a
> descoberto na maré baixa, o que não sucede se a margem for definida como
> riverbank), embora em última análise isso seja uma especificidade do
> mapnik-carto.
>
> Por outro lado, há ainda, por inerência, a questão da exclusão/inclusão
> (imagem inversa) nos polígonos da terra. A linha de água do Estuário do
> Tejo actualmente acaba em frente ao Cais do Sodré (Gargalo do Tejo).
>
> Assim, no instante presente, talvez não fosse má ideia incorporar o Mar da
> Palha simultaneamente na coastline e no multipolígono Iberian Peninsula?
>
> Cump.s,
> H. Valentim
>
>
> De: talk-pt-requ...@openstreetmap.org talk-pt-requ...@openstreetmap.org>
> Enviado: 11 de junho de 2019 13:00
> Para: talk-pt@openstreetmap.org
> Assunto: Talk-pt Digest, Vol 113, Issue 4
>
> Today's Topics:
>
>1. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)
>2. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-pt/attachments/20190613/76fde5d6/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Thu, 13 Jun 2019 21:47:36 +0100
> From: Alexandre Badalo 
> To: talk-pt@openstreetmap.org
> Subject: [Talk-pt] Relações em urbanização
> Message-ID: <14696949-abe3-9ff3-8633-965706e1b...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Boas,
>
>
> Tenho estado a mapear a minha terreola, agora uma das coisas que falta
> são os edificios, eu não tenho bem a certeza como mapear as
> urbanizações, fiz uma assim
> https://www.openstreetmap.org/changeset/71231696 , não sei se as
> relações são necessárias, e se sequer estão bem feitas, podem verificar?
>
>
> No caso dos edificios com lojas em baixo e casas em cima, como devo
> proceder ao mapeamento das lojas/restaurantes/etc? deixo como node?
> Coloco uma relação ao edificio?
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
> --
>
> End of Talk-pt Digest, Vol 113, Issue 6
> ***
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org

Re: [Talk-GB] OS Open Greenspace tileset

[Jez Nicholson]

Nice.

When they released OS Open Greenspace it immediately made me shout. There
are lots of places that they don't regard as greenspace that clearly are,
plus there are nuances.

Can you tell from the render which areas are pulled in from OSM? I'm
comparing the layers in JOSM and can see when an area exactly matches OSM.

Do you want any specific feedback, or is it too early to comment?

Regards,
 Jez

On Fri, Jun 14, 2019 at 10:24 AM Richard Fairhurst 
wrote:

> Hi all,
>
> I've put together a simple tileset showing greenspace areas from Ordnance
> Survey's recent OS Open Greenspace release. The data is released under the
> standard OS open licence therefore suitable for tracing in OSM.
>
> Many features are already in OSM, but not all, and in addition the names
> might be helpful.
>
> The tiles also include a few greenspace-related features from OSM and the
> basic OSM road/path network.
>
> You can add the tiles to your favourite editor using this URL:
> http://osm.cycle.travel/greenspace/{z}/{x}/{y}.png
>
> (The tileserver is a bit slow at small scales right now but I'll optimise
> it later.)
>
> cheers
> Richard
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Need someone in the south to review an edit

[Shawn K. Quinn]

On 6/13/19 23:29, Paul Johnson wrote:
> Brandify put up a rather suspicious mass deletion
>  recently.  I suspect
> that one of their customers stopped paying/had a term contract that
> expired and Brandify mass-deleted the entire chain.  But it is possible
> that the chain went out of business and their website is still active. 
> Could I get someone in the south to take a look at this and see if
> locations near you that was deleted closed?

One of the following changeset comments suggests the deletions in this
changeset are to remove duplicates added by mistake previously.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

[Talk-GB] OS Open Greenspace tileset

[Richard Fairhurst]

Hi all,

I've put together a simple tileset showing greenspace areas from Ordnance 
Survey's recent OS Open Greenspace release. The data is released under the 
standard OS open licence therefore suitable for tracing in OSM.

Many features are already in OSM, but not all, and in addition the names might 
be helpful.

The tiles also include a few greenspace-related features from OSM and the basic 
OSM road/path network.

You can add the tiles to your favourite editor using this URL:
http://osm.cycle.travel/greenspace/{z}/{x}/{y}.png

(The tileserver is a bit slow at small scales right now but I'll optimise it 
later.)

cheers
Richard
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Dave F via talk]

On 14/06/2019 07:57, Mateusz Konieczny wrote:

Edits would be split to not create overly large bounding boxes.


As long as it's clearly commented, I wouldn't loose any sleep over the 
physical size of the changeset. OSM should be concerning itself with 
quality rather than quantity.


That the main website is antiquated & unable to display details of edits 
is not a reason to improve the database efficiently. Performing edits in 
one go makes them easier to keep track of & revert, if there's a problem.


DaveF

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Dave F via talk]

It's taken you longer to write your email than it would to write a line 
of extra code to search for them.


Easier to distinguish between the two:
http://overpass-turbo.eu/s/JWq

DaveF

On 14/06/2019 08:27, Johnparis wrote:

For ATMs, at least, I would propose the opposite: add the atm=yes tag to
all amenity=atm

 From a user perspective, I want to be able to search for atm=yes to obtain
all the nearby ATMs. Removing this tag leaves me without standalone ATMs,
so I would have to search for atm=yes OR amenity=atm

Thus, I don't think this is duplicated information -- it is additional
information. If this were 1965 and we needed to fit everything into 32K of
memory, I'd say fine, but I don't see the need or the advantage.

John


On Fri, Jun 14, 2019 at 9:00 AM Mateusz Konieczny 
wrote:


Recently in mapping I encountered amenity=atm with atm=yes

I manually removed atm=yes, but it turns that there is more of such
objects.
I propose to run an automatic edit that will remove atm=yes from all such
objects.
In addition I propose to remove also some other blatant and unnecessary
duplicates.

So in total I propose to remove

atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
sustenance=restaurant from amenity=restaurant
http://overpass-turbo.eu/s/JWh
sustenance=fast_food from amenity=fast_food http://overpass-turbo.eu/s/JWc
service=post_office from amenity=post_office
http://overpass-turbo.eu/s/JWa

as this duplicated tags are unnecessary, unwanted, confusing and
undesirable.
Edits would be split to not create overly large bounding boxes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk




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


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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Simon Poole]

Please no.

Essentially you are saying that all attribute tags that indicate that a
specific facility is present should be duplicated on the standalone
objects of the same type.

bin=yes on amenity=waste_basket, bench=yes on amenity=bench and so on.

Am 14.06.2019 um 09:27 schrieb Johnparis:
> For ATMs, at least, I would propose the opposite: add the atm=yes tag
> to all amenity=atm
>
> From a user perspective, I want to be able to search for atm=yes to
> obtain all the nearby ATMs. Removing this tag leaves me without
> standalone ATMs, so I would have to search for atm=yes OR amenity=atm
>
> Thus, I don't think this is duplicated information -- it is additional
> information. If this were 1965 and we needed to fit everything into
> 32K of memory, I'd say fine, but I don't see the need or the advantage.
>
> John
>
>
> On Fri, Jun 14, 2019 at 9:00 AM Mateusz Konieczny
> mailto:matkoni...@tutanota.com>> wrote:
>
> Recently in mapping I encountered amenity=atm with atm=yes
>
> I manually removed atm=yes, but it turns that there is more of
> such objects.
> I propose to run an automatic edit that will remove atm=yes from
> all such objects.
> In addition I propose to remove also some other blatant and
> unnecessary duplicates.
>
> So in total I propose to remove
>
> atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
> transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
> sustenance=restaurant from amenity=restaurant
> http://overpass-turbo.eu/s/JWh
> sustenance=fast_food from amenity=fast_food
> http://overpass-turbo.eu/s/JWc
> service=post_office from amenity=post_office
> http://overpass-turbo.eu/s/JWa
>
> as this duplicated tags are unnecessary, unwanted, confusing and
> undesirable.
> Edits would be split to not create overly large bounding boxes.
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Frederik Ramm]

Hi,

On 14.06.19 08:57, Mateusz Konieczny wrote:
> So in total I propose to remove

[...]

Makes sense to me. Please document it on the wiki as per the automated
editing guidlines,

"You should normally document your proposed edit at an English-language
wiki page named "Automated edits/username" (where username is the OSM
user name of the account that you will be using to perform the edits -
think about this now so that you don't have to rename the page later),
and add it to Category:Automated edits log."

Bye
Frederik

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

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

Re: [OSM-talk-fr] Osmose erreurs#1270

[marc marc]

Le 14.06.19 à 08:39, lenny.libre a écrit :
> j'hésite encore entre le noexit et le "man_made=quay"
> https://goo.gl/maps/ezwLyzp122JTQD2U9

j'opterais pour un quai ou un mur de soutènement
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Andrew Harvey]

I think this proposed edit is reasonable, it makes things simpler without
loosing any information.

On Fri, 14 Jun 2019 at 17:30, Johnparis  wrote:

> From a user perspective, I want to be able to search for atm=yes to obtain
> all the nearby ATMs. Removing this tag leaves me without standalone ATMs,
> so I would have to search for atm=yes OR amenity=atm
>

Except you'd already need to search for amenity=atm or atm=yes to find
those amenity=atm's not tagged with atm=yes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Martin Koppenhoefer]

sent from a phone

> On 14. Jun 2019, at 09:27, Johnparis  wrote:
> 
> For ATMs, at least, I would propose the opposite: add the atm=yes tag to all 
> amenity=atm


this doesn‘t seem reasonable, atm=yes is a property to state that the feature 
provides an atm. With amenity=yes it is already implied.

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

Re: [Talk-at] Sammelrelationen XX in YY

[norbert baldia]

Lieber Friedrich!

 

Im Zusammenhang mit "Sammelrelation" - Wanderwege Türnitzer Alpen - würde ich gerne damit in Kontakt treten.

Ich suche schon lange einen OSM-Kollegen aus diesem Raum, der mir, einem eher ungeübten OSM-Beiträger, einige unterstützende praktische Anwendungen erklärt.

 

Mit kollegialen Beobachtergrüßen

 

aus dem (unrechten) Traisental

 

Norbert



Gesendet: Freitag, 14. Juni 2019 um 08:18 Uhr
Von: "Friedrich Volkmann" 
An: "OpenStreetMap AT" 
Betreff: [Talk-at] Sammelrelationen XX in YY

Anlässlich der Relation 9463022 ("Wanderege Türnitzer Alpen") kommt mir vor,
dass diese Art von Relationen überhandnimmt. Im selben Editorfenster werden
mir zufällig auch eine Relation 7293702 "Landesstraßen B in
Niederösterreich" und 939634 "Österreichische Bundesstraßen" gelistet.
Letztere enthält ironischerweise nur solche Straßen, die dem Gesetz nach gar
keine Bundesstraßen mehr sind.

Ich bin dafür, alle derartigen Relationen zu löschen, erstens weil sie den
Regeln widersprechen
(https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories)
und zweitens weil sie die Wartbarkeit der anderen Relationen unnötigerweise
erschweren, indem die Relationenliste im Editor immer länger wird.

--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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




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

[talk-cz] WeeklyOSM CZ 462

[Tom Ka]

Ahoj, je dostupné vydání 462 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/12140

* Aktualizace Strava CZ/SK.
* Problémy s mosty 3D.
* Novinky OsmHiCheck.
* Tagování zaniklé obce.
* Lepší tagování jízdních pruhů.
* Problémy s editorem iD.
* Firemní editoři v OSM.
* Lístky na SotM 2019.
* Data o dopravě od Mapboxu.
* OSM plugin pro WordPress.
* Silnice v Irsku a Hvězdné války.

Pěkné počtení ...

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

Re: [OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Johnparis]

For ATMs, at least, I would propose the opposite: add the atm=yes tag to
all amenity=atm

>From a user perspective, I want to be able to search for atm=yes to obtain
all the nearby ATMs. Removing this tag leaves me without standalone ATMs,
so I would have to search for atm=yes OR amenity=atm

Thus, I don't think this is duplicated information -- it is additional
information. If this were 1965 and we needed to fit everything into 32K of
memory, I'd say fine, but I don't see the need or the advantage.

John


On Fri, Jun 14, 2019 at 9:00 AM Mateusz Konieczny 
wrote:

> Recently in mapping I encountered amenity=atm with atm=yes
>
> I manually removed atm=yes, but it turns that there is more of such
> objects.
> I propose to run an automatic edit that will remove atm=yes from all such
> objects.
> In addition I propose to remove also some other blatant and unnecessary
> duplicates.
>
> So in total I propose to remove
>
> atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
> transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
> sustenance=restaurant from amenity=restaurant
> http://overpass-turbo.eu/s/JWh
> sustenance=fast_food from amenity=fast_food http://overpass-turbo.eu/s/JWc
> service=post_office from amenity=post_office
> http://overpass-turbo.eu/s/JWa
>
> as this duplicated tags are unnecessary, unwanted, confusing and
> undesirable.
> Edits would be split to not create overly large bounding boxes.
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-at] Schule für Shiatsu

[Christian Aigner]

Werte Kolleginnen und Kollegen!

Ich bin gerade dabei, eine Schule für Shiatsu-Ausbildung einzutragen.

Was nehme ich da am besten?

amenity=school

oder die Kombination

amenity=education
education=shiatsu

Oder gar etwas anderes? Wie würdet ihr das eintragen?

Mit besten Grüßen,
Christian

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

Re: [OSM-talk-fr] Osmose erreurs#1270

[lenny.libre]

Le 13/06/2019 à 20:10, deuzeffe a écrit :

On 13/06/2019 17:45, marc marc wrote:


Donc erreur à signaler à osmose ?


à la place d'osmose, j'ignorerais tout ce qui touche
aux highway surfacique, c'est trop immature.
mais sinon oui tu peux essayer de proposer que freed
fasse une rustine sur la rustine pour avoir moins d'anomalie.


Et résoudre l'anomalie en "Faux positif", ça le fait pas ?
Le faux positif fait disparaître le signalement de l'erreur et comme 
elle n'est pas conservée ; je ne l'utiliserai que s'il n'y a pas de 
modif possible pour osmose.


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

[OSM-talk] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Mateusz Konieczny]

Recently in mapping I encountered amenity=atm with atm=yes

I manually removed atm=yes, but it turns that there is more of such objects.
I propose to run an automatic edit that will remove atm=yes from all such 
objects.
In addition I propose to remove also some other blatant and unnecessary 
duplicates.

So in total I propose to remove

atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8 

transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe 

sustenance=restaurant from amenity=restaurant http://overpass-turbo.eu/s/JWh
sustenance=fast_food from amenity=fast_food http://overpass-turbo.eu/s/JWc
service=post_office from amenity=post_office http://overpass-turbo.eu/s/JWa 


as this duplicated tags are unnecessary, unwanted, confusing and undesirable.
Edits would be split to not create overly large bounding boxes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Osmose erreurs#1270

[lenny.libre]

Le 13/06/2019 à 17:45, marc marc a écrit :

Le 13.06.19 à 17:09, lenny.libre a écrit :

Le 13/06/2019 à 12:53, marc marc a écrit :

Le 13.06.19 à 12:44, lenny.libre a écrit :

Est-ce le "area=yes" qui perturbe Osmose

c'est la conclusion à laquelle je suis arrivée

Donc erreur à signaler à osmose ?

à la place d'osmose, j'ignorerais tout ce qui touche
aux highway surfacique, c'est trop immature.
mais sinon oui tu peux essayer de proposer que freed
fasse une rustine sur la rustine pour avoir moins d'anomalie.


J'ai une autre signalement similaire mais le point
https://www.openstreetmap.org/node/4803417553#map=19/45.43701/12.32896  
est à la jonction entre "highway=pedestrian" et le bord du canal : si je

mettais un “noexit” se ne serait pas tout à fait juste, il n'y a pas de
quai, la rue s'arrête au droit du canal et des barques privées y accostent.

il n'y a pourtant aucun mode de transport qui continue de l'un à l'autre
tu peux faire du multimodal (arriver en voiture, continuer en barque)
mais pour chacun des modes l'un des 2 objets (la rue et le canal),
c'est sans issue à ce point là. là aussi à voir si osmose ne devrait
pas simplement s'abstenir.
Mais avec cette logique, il y a plein de cas :
un sentier piéton qui termine en bordure de la pelouse d'un parc
n'empêche pas de continuer à se balader dans le parc

perso j'aurais modifié la donnée dans osm, considérant que la rue
ne se jette pas dans le canal et que donc il n'y a pas de noeud commun
ou s'il y a un noeud commun, c'est une barrière (une vrai barrière
ou un muret de qlq cm pour éviter que l'eau ne coule dans la rue)


Je vais modifier dans osm ; il n'y a ni barrière, ni muret (voir photos 
ci-dessous) j'hésite encore entre le noexit et le "man_made=quay" 
proposé par Jean-Yvon que je trouve pas mal...


Pour montrer, je n'ai pas trouvé de photo sur mapillary (à l’époque je 
ne l'utilisais pas non plus)  mais avec 
https://goo.gl/maps/tnr4tWx6iXYnGBYs5 c'est juste sous le balcon et 
https://goo.gl/maps/339Zsmrtxixv13Ji7 qui montre un point similaire plus 
large et vu du canal https://goo.gl/maps/ezwLyzp122JTQD2U9



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

[Talk-at] Sammelrelationen XX in YY

[Friedrich Volkmann]

Anlässlich der Relation 9463022 ("Wanderege Türnitzer Alpen") kommt mir vor, 
dass diese Art von Relationen überhandnimmt. Im selben Editorfenster werden 
mir zufällig auch eine Relation 7293702 "Landesstraßen B in 
Niederösterreich" und 939634 "Österreichische Bundesstraßen" gelistet. 
Letztere enthält ironischerweise nur solche Straßen, die dem Gesetz nach gar 
keine Bundesstraßen mehr sind.


Ich bin dafür, alle derartigen Relationen zu löschen, erstens weil sie den 
Regeln widersprechen 
(https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories) 
und zweitens weil sie die Wartbarkeit der anderen Relationen unnötigerweise 
erschweren, indem die Relationenliste im Editor immer länger wird.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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