[talk-cz] WeeklyOSM CZ 478

[Tom Ka]

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

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

* Várka novinek freemap.sk.
* Mapování solárů v UK.
* Bezobalové obchody.
* Kontrola tagování.
* Výsledky dotazníků OSM.
* Videa ze SotM US.
* Svatí v Evropě.
* CC-BY a použití v OSM.
* Novinky StreetComplete.
* Stav Galileo.
* Kniha Proč mapy lžou?
* Pátky pro budoucnost.

Pěkné počtení ...

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

Re: [talk-au] Discussion D: mapping ACT for cyclists – complying with ACT law

[Herbert.Remi via Talk-au]

There are almost no paths in the ACT compliant with Australian Tagging 
Guidelines and ACT law. You can visualise these for yourself. The script should 
turn up thousands of hits but there are almost none.
Try this overpass turbo script.
https://overpass-turbo.eu/s/MQp

‐‐‐ Original Message ‐‐‐
Am Samstag, 28. September 2019 00:02 schrieb Herbert.Remi 
:

> # Discussion D: mapping ACT for cyclists – complying with ACT law
> I hope you can help.
> (If you open this plain text post to a markdown editor it will be fully 
> formated. I recommend Typora.)
> Abbreviation: ATG - Australian Tagging Guidelines
>
> ## The Issue
> The way you use a map changes the way you see it. I am very interested in 
> cycling. I am interested in capturing the information for cyclable paths so 
> that maps can be made for all types of biking, including MTBs.
>
> The situation for OSM in the ACT for cyclists is unfortunate. The paths you 
> are allowed to ride with a bike are completely inconsistently tag. The cause 
> is no logical inconsistency between the ATG, the editor presets, the standard 
> rendering practice, and finally the many ways creative mappers have tried to 
> solve the problem in the last decade.
>
> The last is tragic and frustrating as mappers continually undo other mappers 
> work and redo the tags their own preferred way. Over time, the path tagging 
> does not improve but across the ACT become increasingly randomise. Where the 
> congested areas it happens most often. The paths in Commonwealth Park on Lake 
> Burley Griffin has been retagged over and over again, many times each year. 
> Some paths alternate regularly between the footpath and bike path preset, 
> even though neither applies in the ACT according to the ATG. ☹
>
> ### Table of ID Editor presents, path types and rendering for each environment
> | ID preset   | Correct in the ACT
> | tagging  | ID 
> editor line style | Mapnik line style |
> | --- | 
> - | 
>  | 
>  | - |
> | ATG and ACT law (Path   shows as the preset symbol) | Legal default path   
> type | highway=path   bicycle=designated   foot=designated   segregated=no | 
> grey/brown dotted| blue dotted   |
> | cycle path  | No
> | highway=cycleway | blue 
> dotted  | blue dotted   |
> | cycle and foot path | No but close  
> | highway=cycleway   bicycle=designated   foot=designated  | blue 
> dotted  | blue dotted   |
> | foot path   | No
> | highway=footway  | grey 
> dotted  | red dotted|
> | cycle ONLY – no   preset| Yes (rare)
> | highway=path   bicycle=designated   foot=no  | 
> grey/brown dotted| blue dotted   |
> | pedestrian ONLY – no   preset   | Yes (rare)
> | highway=path   bicycle=no   foot=designated  | 
> grey/brown dotted| red dotted|
>
> Finally, I suggest one simplified way of path tagging for the ACT at the 
> bottom of this text.
>
> QUESTION
> **What is the best way to restore consistency across the OSM data set for the 
> ACT?**
>
> ## Most commonly used keys
> These keys are for bike and footpaths: highway, foot, bicycle, footway, 
> segregated. The tags used in the ACT OSM maps in all combinations are found 
> below. The tags foot=no or bicycle =no is only correct when the path is 
> signed that way for segregated paths and very few have been built. The key 
> footway is used more commonly in the south of Canberra and seldom used in a 
> way which is consistent with the ATG or ACT law, further increasing the 
> inconsistency.
>
> Any of the following combinations of highway, foot, bicycle, footway, and 
> segregated can be found in the ACT.
> * segregated=no/yes
> * highway=path/footway/cycleway
> * foot=designated/yes/blank/no
> * bicycle= designated/yes/blank/no
> * footway=sidewalk OR missing
>
> ## The ATG says
> Under ACT law, both pedestrian and cyclists are both allowed to use the 
> “footpath”. Here is the relevant section of the ATG.
> “If bicycles are permitted by law then use highway=path.
> **Do not use highway=footway unless bicycles are expressly prohibited from 
> using that path.**”
> Pedestrian ONLY paths are very rare in the ACT.
>
> What is ALSO very rare in the ACT is bike ONLY path, which the ATG calls the 
> “Australian Cycle Path (bicycle-only sign, pedestrians prohibited)”, and the 
> properly separated shared paths, which the ATG 

Re: [Talk-ca] Talk-ca Digest, Vol 140, Issue 11

[keith hartley]

a@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-ca
> >
> >
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> --
>
> Message: 2
> Date: Thu, 3 Oct 2019 11:54:44 -0400
> From: john whelan 
> To: Justin Tracey 
> Cc: Talk-CA OpenStreetMap , Kevin Farrugia
> 
> Subject: Re: [Talk-ca] Postcodes in Canada
> Message-ID:
> <
> caj-ex1f+ubsdr5oq3ooy1o6umxyej5dwjcf4gov1kqdnra6...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Canadian Postal Codes in urban areas are blocks of roughly 50 buildings
> which makes them extremely interesting to use for GIS studies.  Average
> income etc.
>
> Both in the UK and Canada many people would rather type in a 6 character
> code than a street address with city when looking for directions to a
> location.  In the UK postcodes where restricted to a street which meant
> when computer storage was expensive we used something called a prem code
> which was the building number followed by the postcode and generated the
> full address when required.  Canadian postcodes can spam different streets
> especially in areas served by supermail boxes.
>
> If I use  the example of my own address.  The house was built in the City
> of Cumberland, but my postal address was Navan.  Then Canada Post changed
> the postal address to Orleans which is interesting as Orleans does not
> exist as a municipality.  Apparentyl there are one or two other places in
> Canada that Canada Post doesn't use the municipality name in the postal
> address.  Currently it is in the City of Ottawa so some mail gets addressed
> Orleans and some Ottawa.  I had an elderly aunt who always addressed my
> Christmas card to Navan and included the postcode until she died and each
> year the post office would attach a sticker saying the postal address was
> wrong.  The post code remains the same over all the changes.
>
> So yes a postcode can change but from time to time they are more stable
> than the official postal address.
>
> As long as one address contains the postcode then Nominatim will find it
> which means it can be used for directions.  You might be 30 buildings away
> but you are in the right general area so I think adding them as part of a
> street address is of value.
>
> Cheerio John
>
>
>
> On Thu, 3 Oct 2019 at 11:24, Justin Tracey  wrote:
>
> > In the US, ZIP Codes (the US postal code equivalent) are frequently
> > emphasized to not correspond to geographic locations, but sets of
> > addresses. Of course they frequently cluster according to geography (and
> > the prefixes are indeed assigned to states and regions within the
> > state), and are often used as stand-ins, but you can't make assumptions
> > about continuity or proximity for the addresses they correspond with.
> > Even though I can't find it explicitly worded that way (i.e., "post
> > codes are address sets, not locations"), it seems to be the same
> > situation here. Given that, the most "correct" thing to do would be
> > tagging postal codes in addresses, and not as distinct entities.
> >
> > The Canada Post website has a tool to lookup the postal code for a
> > particular address, so if it were released, wouldn't the data they use
> > to supply that information be good enough for this? It doesn't quite
> > solve people trying to navigate "to" a particular postal code, but it
> > seems like that's an ambiguous request anyway.
> >
> >  - Justin
> >
> >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20191003/6175e7e4/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Thu, 3 Oct 2019 12:53:22 -0400
> From: "Alouette955" 
> To: "Talk-CA OpenStreetMap" 
> Subject: [Talk-ca] Pertinence de lcn=yes pour le Québec
> Message-ID: <23E127B36E5B4153AC238E746E2817E5@ToshibaCL>
> Content-Type: text/plain; charset="utf-8"
>
> Bonjour,
>
> J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le
> changement d’objet de la conversation.
>
> Le message original couvrant les autres sujets se trouve ici:
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html
>
> Afin de bien mesurer l’ampleur j’ai sorti ces données concernant
> l’utilisation du lcn=yes dans les chemins (ways) et network=lcn dans les
> relations p

Re: [Talk-GB] Import UK postcode data?

[ndrw6]

On 04/10/2019 00:26, Dave F via Talk-GB wrote:
I think you're missing the point. Most contributors believe postcodes 
on buildings or property nodes, add quality to the OSM's database, but 
object to the import of codepoint as it's just not accurate enough as 
stated in this, & numerous other threads.


This is incorrect. CPO/ONSPD postcodes _are_ accurate, up to date and 
include all postcodes in the UK except NI. They are not complete 
(contain one and only one delivery point per postcode), which is pity, 
but that's not a reason not to use the ones that are available, which is 
still _far_ more that what we have in the database.


This may not be a perfect solution but the information CPO/ONSPD 
contains is still extremely useful for geocoding. Search for a postcode 
and you are _guaranteed_ to get an address in a close vicinity to a 
place you are looking for. How about not needing to start Google Maps 
when searching for a location on the go?


There's no point in importing to stand alone nodes as deliveries are 
destined for buildings. Adding to streets is also pointless for the 
same reason plus they can have multiple postcodes.


Addresses on nodes are commonly used in the UK OSM. Many mappers prefer 
them over placing addresses on buildings. There are also many cases 
(POIs) where nodes are objectively better than buildings. So, no, there 
right and wrong solution here.


Besides, the main reason for importing these data is that we can get 
_all_ postcodes in the database. This gives users confidence that when 
they search for a postcode they will reliably get a result they are 
looking for. This is not possible when merging postcodes with buildings 
simply because we still have only a small fraction of buildings in the 
database.


By the way, I'm not against merging addr:postcode with buildings, that's 
exactly what I was doing myself when adding postcodes manually. However, 
this is not a process that can be automated (lack of buildings, single 
OSM buildings having more than one address/postcode). Based on my 
experience with mapping postcodes with CPO, I would recommend starting 
with an import and merge postcodes and buildings later.


ndrw6



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

Re: [Talk-GB] Import UK postcode data?

[Dave F via Talk-GB]

I think you're missing the point. Most contributors believe postcodes on 
buildings or property nodes, add quality to the OSM's database, but 
object to the import of codepoint as it's just not accurate enough as 
stated in this, & numerous other threads.


There's no point in importing to stand alone nodes as deliveries are 
destined for buildings. Adding to streets is also pointless for the same 
reason plus they can have multiple postcodes.


DaveF

On 03/10/2019 01:40, nd...@redhazel.co.uk wrote:

On 02/10/2019 13:43, Russ Phillips via Talk-GB wrote:
I'm wondering if it would be feasible and advisable to import the UK 
postcode data from OS OpenData Codepoint 
. 




I support it. From my own experience, requests like this tend to 
attract objections, so it is important for people who agree with such 
proposals to speak out.


The key and, in my opinion, sufficient reasons for importing postcodes:

- Objectively, postcodes are an important type of addressing and 
geocoding data in the UK. We've had two quarterly projects encouraging 
adding postcodes to the OSM database. Some people (including myself) 
don't like the fact the postcodes are proprietary to Royal Mail but we 
are here to map the world, not to judge it.


- They are accepted in the OSM database and there is no tagging 
ambiguity. Their place is _in_ the OSM database, not in external 
overlays. They are searchable in most applications (OsmAnd, Maps.me), 
the exception is Nominatim, which uses an outdated overlay but this is 
more a workaround for lack of such data in the database, than a solution.


- Code-Point Open is a legal and open source of postcode data. In fact 
it is the _only_ legal source of such data in bulk. All other sources 
are either derived from CPO or are based on local knowledge.


All reasons _against_ the import I've seen so far are based on 
personal preferences. People are objecting because they don't like the 
idea of proprietary address data, do not find them important enough, 
do not find them comprehensive enough. These views are useful in 
establishing the context but are not a reason to block the import of 
what _is_ available.


Talking about technical aspects:

- The key (and deliberate) limitation Code-Point Open is that it 
doesn't distinguish between residential postcodes and postcodes 
assigned to "large users". This is not ideal but still useful - we 
know the postcode exists at a given location, we just can't be sure if 
it is the only postcode there.


- Quality of building in OSM database. Large buildings, especially in 
town centres, are often not partitioned correctly. Different parts may 
have different street names and postcodes. Code-Point Open may in fact 
be helpful in finding and correcting such issues.


- Some postcodes are for PO boxes (usually collocated with post 
offices) are are best left out.


My recommendation: import missing postcodes "as is" (as points) with 
extra tags denoting the import, import date and an accuracy metric 
from CPO. Keep it searchable and easy to remove or update, if 
necessary. Code-Point Open is updated quarterly and sometimes 
centroids move to another building. Filter out PO boxes and postcodes 
which are already in OSM (I usually check if there is an OSM object 
with a matching addr:postcode within a 10m radius of the code point). 
Do not attempt to merge them with buildings as it is not guaranteed to 
work in all cases. This is best done manually and in some cases it may 
require a survey.


Best regards,

ndrw6



___
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-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[Friedrich Volkmann]

On 03.10.19 23:44, vari...@mailbox.org wrote:
Die Frage ist, ob 130k 
wirklich genug ist um von "Akzeptiert weil genug benutzt" zu reden. 
https://taginfo.openstreetmap.org/keys/name%3Aprefix ich glaube eher nicht :)


130k hört sich imposant an, aber wenn man die Verbreitungskarte und die 
häufigsten Werte ansieht, erkennt man rasch, dass dieser Key auf wenige 
Länder beschränkt ist. Und teilweise wurde er in Massenedits (z.B. 52736774) 
hinzugefügt, die nicht so aussehen, als wär damit der automated edits code 
of conduct eingehalten worden.


Man kann aber auch nachträglich ein Proposal erstellen dafür - aber warum 
unbedingt einen neuen Tag erfinden und nicht einen bestehenden benutzen?


Weil es dir schwer fallen wird, für name:prefix eine Bedeutung zu 
definieren. Und weil es für manche Länder nicht verwendbar ist.


--
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] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[various]

Das umgetagge finde ich nicht gut. Vor allem, wenn sowieso nix klar ist. Aber 
nach einigem durchlesen fände ich es wenigstens besser, wenn name:prefix=* 
statt :at=* benutzt wird. name:prefix=* wird inzwischen immerhin wenigstens ein 
paar mal Weltweit benutzt. Die Frage ist, ob 130k wirklich genug ist um von 
"Akzeptiert weil genug benutzt" zu reden. 
https://taginfo.openstreetmap.org/keys/name%3Aprefix ich glaube eher nicht :)

Man kann aber auch nachträglich ein Proposal erstellen dafür - aber warum 
unbedingt einen neuen Tag erfinden und nicht einen bestehenden benutzen?

> andreas wecer  hat am 3. Oktober 2019 um 23:11 
> geschrieben:
> 
> Sehe ich das eigentlich richtig? Ein einzelner User hat vor 5 Jahren in 
> ganz Österreich alle möglichen Bezirke auf "name:prefix:at" umgetaggt, wovon 
> er nach einiger Zeit offenbar selbst nicht mehr überzeugt war
> 
> http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tt270.html#a382
> 
> http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Gemeinde-Relationen-in-Osterreich-Abweichende-Schreibweisen-tp1288p1290.html
> 
> Es konnte anscheinend bis jetzt noch niemand erklären, was das ":at" 
> überhaupt soll, sondern es wurde mehrfach von verschiedenen Leuten darauf 
> hingewiesen, dass das überhaupt keinen Sinn ergibt
> http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p372.html
> http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p379.html
> http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p384.html
> http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p386.html
> https://forum.openstreetmap.org/viewtopic.php?pid=732637#p732637
> 
> Dennoch wird es immer noch weiter verwendet und kommt mittlerweile 2429 
> mal vor (während es bspw. gerade einmal 70 name:prefix:de gibt), weil die 
> Alternativen auch alle irgendjemand nicht passen, weil es mittlerweile schon 
> immer so war und weil von den Varianten mit der getrennten Speicherung 
> sowieso keine irgendwo unterstützt wird?
> ___
> 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: [OSM-talk-fr] Lieux-dits Fantoir surfaciques

[Vincent de Château-Thierry]

Bonsoir,

Le 03/10/2019 à 22:42, osm.sanspourr...@spamgourmet.com a écrit :


Du coup avec l'interface JOSM j'ai vu qu'un lieu-dit c'était plus qu'un 
place=unknown.


C'est aussi dans certains cas un périmètre.

Est-ce que ça ne vaut pas le coup de tenter de faciliter leur intégration ?


Tout ton propos est centré sur la technique, le "comment faire" : le 
greffon, la topologie, faire des relations pour ne pas dupliquer, etc.
Il faudrait peut-être avant tout ça se poser la question du sens ? La 
technique suivra, le souci n'est pas là.


Ce que j'appele "lieux-dits" dans le contexte de BANO ce sont les nodes 
place=*, essentiellement place=hamlet, place=isolated_dwelling et 
place=locality. Ce sont des points la majeure partie du temps car on est 
bien en peine de définir leurs contours aussi précisément que pour une 
commune. Côté Cadastre on a parfois (mais pas toujours) des parcelles 
nommées et c'est à première vue une manière de définir l'emprise d'un 
lieu-dit. Sauf qu'il n'est pas rare que la partie habitée, celle le long 
de la route, avec de petits panneaux en noir et blanc porteurs du nom du 
lieu-dit, ne soit pas incluse dans les parcelles nommées.


Je n'ai pas l'impression qu'on gagnera en pertinence en important des 
agrégats de parcelles nommées issues du cadastre (notre seule source 
surfacique) tant c'est un contenu partiel (on a bien plus de lieux-dits 
sur le terrain que de parcelles nommées côté Cadastre) et arbitraire, 
voire divergent par rapport au terrain.


vincent


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

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Sehe ich das eigentlich richtig? Ein einzelner User hat vor 5 Jahren in
ganz Österreich alle möglichen Bezirke auf "name:prefix:at" umgetaggt,
wovon er nach einiger Zeit offenbar selbst nicht mehr überzeugt war
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tt270.html#a382
http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Gemeinde-Relationen-in-Osterreich-Abweichende-Schreibweisen-tp1288p1290.html

Es konnte anscheinend bis jetzt noch niemand erklären, was das ":at"
überhaupt soll, sondern es wurde mehrfach von verschiedenen Leuten darauf
hingewiesen, dass das überhaupt keinen Sinn ergibt
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p372.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p379.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p384.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p386.html
https://forum.openstreetmap.org/viewtopic.php?pid=732637#p732637

Dennoch wird es immer noch weiter verwendet und kommt mittlerweile 2429 mal
vor (während es bspw. gerade einmal 70 name:prefix:de gibt), weil die
Alternativen auch alle irgendjemand nicht passen, weil es mittlerweile
schon immer so war und weil von den Varianten mit der getrennten
Speicherung sowieso keine irgendwo unterstützt wird?
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-GB] Import UK postcode data?

[ndrw6]

On 03/10/2019 09:26, Mark Goodge wrote:
- The key (and deliberate) limitation Code-Point Open is that it 
doesn't distinguish between residential postcodes and postcodes 
assigned to "large users". This is not ideal but still useful - we 
know the postcode exists at a given location, we just can't be sure 
if it is the only postcode there.


ONSPD solves this problem, because it includes the "large user" flag.


That would be very useful, indeed. I didn't know ONSPD has it. From a 
cursory look at it in the past, I've got an impression it was simply a 
repackaged Code-Point Open plus some ONS specific data.


The data format itself is not a big issue. To do any nontrivial data 
processing we still need to import data into something like GeoPandas 
and run some queries in there. Not that GeoPandas is that great either 
(the key feature, spacial join, is not accelerated) but that's a 
separate topic.


ndrw6



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

[OSM-talk-fr] Lieux-dits Fantoir surfaciques

[osm . sanspourriel]

Le 03/10/2019 à 14:24, Brice MALLET - brice...@free.fr a écrit :


Merci pour le travail réalisé / encore à réaliser.

+1

> Il reste à y (re)brancher les lieux-dits

Du coup avec l'interface JOSM j'ai vu qu'un lieu-dit c'était plus qu'un
place=unknown.

C'est aussi dans certains cas un périmètre.

Est-ce que ça ne vaut pas le coup de tenter de faciliter leur intégration ?

Une intégration "brute" avec le greffon JOSM pose problème car les
polygones sont jointifs et on abouti naturellement à des chemins dupliqués.

Il faut donc comme pour les communes découper en segments et créer une
relation type=boundary, boundary=place, place=, name= avec

 * en membres outer le contour découpé en segments

Contours éventuellement sans attributs ?
Avec name:left et name:right? Ce serait incompatible avec des rues
jouant le rôle de limite (qui ont souvent le même nom des deux côtés).
Avec le niveau le plus haut de place des deux place ? et boundary=place
? Ce serait homogène avec les boundary=administrative. Mais comme le nom
peut être celui d'une rue et non d'un boundary=place, ce serait
peut-être déroutant.

 * en membre label le "centre" avec lui aussi les attributs name= et
   place=. C'est homogène avec les boundary=administrative. Note : il y
   a des propositions de changer label en waypoint ou reference_point
   car c'est endroit où l'on va par défaut quand on nous dit d'aller
   dans ce lieu sans plus de précision.

Christian va me dire que name= et place= ne sont pas nécessaires sur le
nœud.
D'un point de vue théorique je suis d'accord.
D'un point de vue pratique sans cela, le style par défaut de la
fondation n'affiche rien et il est classique que les utilisateurs de
données s'attendent à n'avoir qu'un point prêt à l'emploi. Sur les
admin_centre des boundary=administrative il y a aussi duplication des
infos de la relation.

Exemples contigus :
https://www.openstreetmap.org/relation/10060749#map=19/47.78701/-3.48695
https://www.openstreetmap.org/relation/10110420#map=19/47.78696/-3.48731

A priori en créant des points et en créant des segments on peut faire un
CSV  à transformer en pilote
virtuel vrt que l'on peut exporter à son tour en GeoJSON.

https://github.com/topojson/topojson permet de transformer du GeoJSON en
TopoJSON.

Dit comme ça, ça semble simple, il y a quand même un peu de topologie à
faire, peut-être qu'une bibliothèque QGIS, python ou une requête PostGIS
permet de partir des données récupérées par le greffon cadastre (les
fichiers edigeo-.tar.bz2), je suppose que
Vincent et/ou Christian sauront éclairer notre lanterne.

En extrayant en même temps routes et lieux-dits on doit arriver à éviter
les doublons et à créer des segments (dans mon exemple j'ai dû
saucissonner la rue Général De Gaulle, ça aurait pu être fait
automatiquement par topologie.

Pour la petite histoire

cette modélisation résout le problème d'affichage des places en
surfacique signalé sur le style principal.

Jean-Yvon

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

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[Friedrich Volkmann]

On 03.10.19 20:58, eest9 wrote:

Verstehe nicht warum wir in Österreich einen Sonderweg einnehmen sollten


Ich auch nicht. So schwindlige Tags, die nicht mal dokumentiert, geschweige 
approved sind und die nur in einzelnen Ländern in Gebrauch sind 
(designation=* in UK, name:prefix=* in DE, official_status=* in RU), werden 
sich international nie durchsetzen und wir sollten keinen Gedanken mehr 
daran verschwenden.


ein kurzer Blick nach 
Deutschland zeigt auf, dass auch hier die Prefixes nicht im Namen stehen, 
etwa hier: 
https://www.openstreetmap.org/relation/966163#map=13/49.3496/11.2594


Wenn du genauer hinschaust, wird dir auffallen, dass die nächsthöhere 
Einheit (ID=62744) "Landkreis Nürnberger Land" heißt. Und gleich angrenzen 
tut der "Landkreis Roth" (ID=62431). Also sehr wohl die Prefixes im Namen.


Darauf hat Andreas Wecer gestern schon hingewiesen. Ist es dir zu mühsam, 
eine Diskussion zu lesen, bevor du etwas dazuschreibst? Was glaubst du, was 
passiert, wenn das alle so machen?


die 
programmierten Anwendungen sind also nicht darauf ausgelegt, dass das Prefix 
direkt im Namen steht


Doch, das sind sie. Siehe Standardkarte, wo diese Taggingvariante die 
einzige ist, die unterstützt wird.


Das wir es also in 
einem extra Tag erfassen sollte ausreichen. Mir konnte zumindest noch 
niemand schlüssig erklären warum es nicht ausreichen sollte


Die Frage musst du dir erst mal selber stellen, denn du hast nicht für mein 
Proposal gestimmt, in dem ich genau so ein Tag vorgeschlagen habe.



und die letzten Jahre hat es doch auch kein Problem damit gegeben


Wenn du persönlich kein Problem damit hast, heißt das noch lang nicht, dass 
es keines gibt. Ich z.B. habe immer wieder Probleme damit, wenn ich für den 
Höhlenkataster den Gemeindenamen angeben muss und in der Karte die Gemeinden 
nicht von den Bezirken unterscheidbar sind. Wenn ich nicht mal als lokaler 
Mapper mit so einem Sauhaufen arbeiten kann, wie sollen gewöhnliche Anwender 
es dann erst können?


Das ist halt ein Fehler vieler Mapper, dass sie nur den Bildschirm vor sich 
sehen und nicht die Bedürfnisse der Anwender. Mappen als Computerspiel, 
nicht zur Schaffung von Mehrwert für andere. Darum sind auch jene 
Validatoren so beliebt, wo man sich wie Pacman durch die Levels frisst, 
sowie eine Gamingplattform mit dem bezeichnenden Namen Maproulette.


--
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-ca] Carte velo CyclOSM et Référence Route Verte

[Alouette955]

Bonjour,

La modification étant facile à mettre en oeuvre et à renverser le changement de 
RCN à NCN pour la route verte a été effectuée conformément au “tagging 
guideline canadien”. L’apparition de la modification sur la carte cyclable 
pourrait réveiller l’intérêt certains contributeurs et on avisera.

Voir le groupe de modification  https://www.openstreetmap.org/changeset/75251401

La discussion concernant lcn=yes se poursuit dans un autre fil de discussion.

Claude

From: Pierre Béland 
Sent: Tuesday, October 1, 2019 4:09 PM
To: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 
Subject: Re: [Talk-ca] Carte velo CyclOSM et Référence Route Verte


Le wiki résume la réflexion à un certain moment donné et il faut être capable 
de le réviser si nécessaire. Tout comme pour le réseau routier, il y a place à 
l'interprétation lorsque nous hiérarchisons un réseau.  Il faut lui donner du 
sens, et puis oui réduire le bruit avec tous les petits segments très locaux. 


1- L’utilisation de lcn=yes


Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.


2- LCN, RCN ou NCN

Le réseau Route Verte parcourt l'ensemble du Québec. Des relations nationales 
telles que la Trans-Canadienne ne fait que fédérer ces réseaux provinciaux et y 
ajouter son label.  Je suis d'accord pour classer la route verte comme niveau 
NCN.  La classification RCN pourrait elle être réservée à des routes plus 
régionales, traversant quelques municipalités par exemple.

3. Abbréviation RV
D'accord pour enlever tiret. Cela est superflu et prend trop de place.

4. TCT

STC En Français TCT en anglais, la meilleure façon d'harmoniser à travers le 
Canada  c'est d'utiliser TC. Cela sera aussi plus court et permettra de mieux 
distinguer route verte lorsque les deux réseaux sont mentionnés.

Je suggère donc d'utiliser TC au Québec. Et nos collègues des autres provinces 
pourront décider à leur tour s'ils souhaitent harmoniser avec TC, plus neutre, 
non relié à une langue particullère.



Pierre 



Le mardi 1 octobre 2019 13 h 22 min 47 s UTC−4, Alouette955 
 a écrit : 


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

Martin soulève 2 problèmes déjà soulignées par le passé qui méritent chacun 
d’être abordé, peut-être dans des “threads” séparés.

1- L’utilisation de lcn=yes

Très peu de relations de type lcn existent au Québec. Ça semble culturel. 
Contrairement à Toronto où les routes sont des entités connues avec une 
signalisation numérotée claire (ça se voit sur la carte cyclable: 
https://osm.org/go/ZX4unwl--?layers=C), au Québec on a des pistes cyclables 
locales qui tout au plus portent le nom de la rue sur laquelle elle sont 
tracées.

Quand j’ai commencé à m’intéresser aux réseaux cyclables j’avoue avoir fait 
preuve de mimétisme ... lcn (Local Cycle Network) était surtout appliqué aux 
chemins et non à des relations. On semblait vouloir indiquer que la piste est 
de responsabilité municipale (locale). J’ai alors pris ça pour la règle.

C’était une erreur et je l’admets. Depuis lors j’utilise lcn=yes pour démontrer 
qu’une piste cyclable assez longue permet de transiter entre les quartiers. Il 
serait préférable de créer des relations plutôt mais nous n’avons pas de 
signalisation municipale sur quoi se baser.

J’aimerais qu’on puisse discuter un correctif. Pourrait-on retirer lcn=yes des 
chemins afin de créer par la suite les routes pertinentes. Gros travail en vue.

2- LCN, RCN ou NCN

Martin souligne que RCN devrait être réservé aux routes provinciales mais la 
“Canada_tagging_guidelines” dit:
  Signed cycling routes are tagged using the Cycle routes#Relations scheme. 
network=lcn is used for routes within an urban agglomeration, network=rcn 
between agglomerations, and network=ncn for routes spanning an entire province 
or more.
Je sais qu’on peut trouver des indications contradictoires sur le wiki. 
Peut-être ne suis-je pas encore tombé sur la règle expliquée par Martin.

J’ai donc considéré rcn les routes qui traversent des agglomérations sur une 
longue distance comme celles indiquées par Martin. Et évidemment lcn celles de 
la responsabilité d’une agglomération comme Montréal, Laval, Québec, etc ...

Doit-on revoir collectivement cette façon de faire?


Claude

 Virus-free. www.avg.com  
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ee] Maa-amet Tase 6 (maaüksuse nimi) – addr:place või addr:housename?

[SviMik via Talk-ee]

It should be added to all buildings then if you want to use it in that way. I 
can do that too, but we need some agreement on this. Either we use it or not, 
or use it in some particular cases (then we need to decide in which cases).

My idea was to use addr:country=EE along the border only (10-20km). That would 
help to resolve the ambiguity when people extract countries by a simplified 
.poly outline (it's always a simplified one, because the true Estonia border 
cosists of 10335 nodes).

Other options would be to either use it everywhere, or to remove it completely.

Leaving things in a chaotic state because people can't decide is probably the 
worst option. Any other option would at least have some thoughts behind it and 
explanation why it's done in that way.

What's the global practice with this tag? The only thing I've found in wiki is:
"Using addr:country=*, addr:state=*, and addr:province=* are optional, since 
they can almost always be determined from boundary relations."

Taginfo doesn't help either:
https://taginfo.openstreetmap.org/keys/addr:country#values
I don't know what to make out of this.

Четверг,  3 октября 2019, 21:56 +03:00 от "Manuel Hohmann" 
:
> I would not remove addr:country=EE, in particular not as a mechanical edit.
> For a human user the country may be obvious, but for software it is much
> simpler to read the tags of an object than to find administrative borders,
> construct their geometry and determine whether a given address is within that
> border or not.
> 
> On 03.10.19 21:42, SviMik via Talk-ee wrote:
> > I think I agree with you that the addr:country=EE tag is redundant,
> especially far from the border. Do you think it's okay if I remove this tag
> automatically from all building further than 20km from the border? Like that:
> http://svimik.com/osmaddrcountryremoval1.png
> 
> 

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

Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles (code postal)

[deuzeffe]

On 02/10/2019 19:50, Rpnpif wrote:

Le  2 octobre 2019, osm.sanspourr...@spamgourmet.com a écrit :


Le 02/10/2019 à 12:10, Rpnpif - rpn...@trob.eu a écrit :

Bonjour,

Merci à Christian pour la nouvelle API de consultation du géocodeur de
http://demo.addok.xyhz/.


Il n'y pas un h en trop que tu as oublié de fumer ? ;-)


Oups oui, d'où vient ce h parasite ?
http://demo.addok.xyz/ c'est mieux.


Mon FF 60.9.0esr refuse de l'afficher, snif
(oui, j'ai désactivé tous les bloqueurs d'intrus que j'ai pu et non, le 
code de la page n'est pas vide) re-snif


--
deuzeffe, frustrée

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

Re: [OSM-talk-fr] Amenity=telephone

[deuzeffe]

On 02/10/2019 17:07, Laurent Magréault wrote:

Bonjour,


Bonsoir,


A titre de retour d'expérience, je viens d'en dégommer 12 sur 39 dans le
Jura en utilisant comme source Mapillary et les compte-rendus de conseils
municipaux qui se font souvent l'écho de la disparition des cabines.
On a une cabine qui est bien devenue une boîte à livres à Conliège. J'ai
préféré mettre was:amenity=telephone que historic=telephone 


Et ajouter amenity=public_bookcase je présume ?

--
deuzeffe

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

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[eest9]

Bin aus ober erwähnten Beweggründen für umgekehrt. Verstehe nicht warum wir
in Österreich einen Sonderweg einnehmen sollten, ein kurzer Blick nach
Deutschland zeigt auf, dass auch hier die Prefixes nicht im Namen stehen,
etwa hier:
https://www.openstreetmap.org/relation/966163#map=13/49.3496/11.2594 , die
programmierten Anwendungen sind also nicht darauf ausgelegt, dass das
Prefix direkt im Namen steht und das würde erst recht wieder bedeuten das
andere Anwednungen in Österreich nicht gut funktionieren. Dort wird das
Prexif, was ich in meinem Beispielen sah, übrigens gar nicht erfasst. Das
wir es also in einem extra Tag erfassen sollte ausreichen. Mir konnte
zumindest noch niemand schlüssig erklären warum es nicht ausreichen sollte
und die letzten Jahre hat es doch auch kein Problem damit gegeben, ohne
Sachliche Änderung an der Situation (also aufgetretenes Problem) halte ich
also die Überlegungen aus 2014/2015 weiterhin für ausreichend.
lg eest9

Am Do., 3. Okt. 2019 um 19:38 Uhr schrieb Johann Haag :

> Die Angelegenheit ist ziemlich einfach.
> Entscheidet Euch für eine der beiden Varianten, die Festlegung gilt dann
> für gesamt Österreich.
> In Tirol und Vorarlberg genügt ein einfaches Revert, im Osten dann weg mit
> den Gemeinde Präfixen. Oder umgekehrt.
> Ich bin da sehr aufgeschlossen.
>
>
> Grüße Johann Haag
>
> Am 01.10.2019 um 18:48 schrieb PPete :
>
> Mir ist aufgefallen, das kürzlich in Tirol und Vorarlberg die Namen vieler
> Gemeinde- und Bezirksrelationen verändert werden. Z.b:
> https://www.openstreetmap.org/changeset/75069032
>
> Ich weiß, dass das ein sehr ambivalent diskutiertes Thema ist, und es
> meines Wissens nach dazu in Österreich keinen Konsens gibt, ob man z.b. die
> Wörter "Gemeinde" und "Bezirk" in den name-Tag packt, in einen prefix-Tag
> oder sonstwo hin. Auf jeden Fall erstellt diese Umbezeichung aus
> derzeitiger Sicht keine Verbesserung der vorhanden Daten da und erzeugt
> ohne vorige Diskussion und Übereinkunft im Forum oder in der Mailingliste
> sicherlich Spannungen in der Communtiy.
>
> Ich für mich würde z.b. eine Umbennung durch einen einzelnen Mapper ohne
> vorige Abstimmung des über mehrere Jahre hinweg vereinheitlichten
> Relationsschemas in Oberösterreich nicht für gut heißen.
> ___
> 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-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-ee] Maa-amet Tase 6 (maaüksuse nimi) – addr:place või addr:housename?

[Manuel Hohmann]

I would not remove addr:country=EE, in particular not as a mechanical edit. For 
a human user the country may be obvious, but for software it is much simpler to 
read the tags of an object than to find administrative borders, construct their 
geometry and determine whether a given address is within that border or not.

On 03.10.19 21:42, SviMik via Talk-ee wrote:

I think I agree with you that the addr:country=EE tag is redundant, especially 
far from the border. Do you think it's okay if I remove this tag automatically 
from all building further than 20km from the border? Like that: 
http://svimik.com/osmaddrcountryremoval1.png




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

Re: [Talk-ee] Maa-amet Tase 6 (maaüksuse nimi) – addr:place või addr:housename?

[SviMik via Talk-ee]

I think I agree with you that the addr:country=EE tag is redundant, especially 
far from the border. Do you think it's okay if I remove this tag automatically 
from all building further than 20km from the border? Like that: 
http://svimik.com/osmaddrcountryremoval1.png


Вторник, 24 сентября 2019, 18:16 +03:00 от "Jaak Laineste" :
> 
> There is a wiki page: https://wiki.openstreetmap.org/wiki/Et:Key:addr ., I
> think it is basically tase 5: housename, tase 6: housenumber if I get the
> question right.
> 
> Feel free to enhance the wiki page, not everyone reads talk-ee, but wiki is
> more official doc :)
> 
> 
> Jaak
> 
> 
> > On 24 Sep 2019, at 17:51, SviMik via Talk-ee 
> wrote:
> > 
> > Hi all,
> > 
> > I have a tagging puzzle here. Maa-amet classifies address parts in the
> following way:
> > 
> > Tase 3 – asustusüksus ja linnaosa
> > Tase 4 – väikekoht
> > Tase 5 – liikluspind (tänav)
> > Tase 6 – maaüksuse nimi
> > Tase 7 – aadressi number
> > 
> > The problem is, that many buildings in Estonia do not have Tase 5 (street
> name), but instead have Tase 6 (lot name) and may or may not have Tase 7
> (housenumber) at the same time.
> > 
> > According to OSM wiki, addr:place is "part of an address which refers to the
> name of some territorial zone".
> > Looks perfect so far, "the name of some territorial zone" is literally
> "maaüksuse nimi".
> > But...
> > 1. addr:place requires place=* node or area to be mapped too, which is not
> really doable for every land lot.
> > 2. I'm already using addr:place for Tase 4 (väikekoht, aiandusühistu, etc)
> which fits better for this role.
> > 
> > We could use addr:housename for this instead.
> > Indeed, Tase 6 is often used as a replacement for the street+number scheme,
> and in most cases is literally the property name.
> > But...
> > 1. Sometimes Tase 6 comes with Tase 7 (housenumber). I'm not sure if
> addr:housename can be used together with addr:housenumber, the addr:housename
> sounds like it must be the final address part.
> > 
> > Examples with house number:
> > 
> > Harju maakond;Kuusalu vald;Leesi küla;Kasemäe;1
> > Harju maakond;Kuusalu vald;Leesi küla;Kasemäe;2
> > - here Kasemäe is tase6, not street (tase5), but it still uses house
> numbering. This example looks like addr:place.
> > 
> > Lääne-Viru maakond;Kadrina vald;Arbavere küla;Palkoja baas
> > Harju maakond;Kuusalu vald;Vihasoo küla;Pumbamaja
> > Harju maakond;Anija vald;Härmakosu küla;Härmakosu tehnopark
> > - here the last part is tase6 too. They don't have house numbers, and these
> examles do look like addr:housename.
> > 
> > So, the questions is: where exactly do I put the Maa-amet "Tase 6" address
> part in OSM tagging scheme?
> > And is it OK to use addr:housename together with addr:housenumber?
> > 
> > --
> > SviMik
> > ___
> > Talk-ee mailing list
> > Talk-ee@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ee
> 
> 


-- 
Svjatoslav Mikhailov
___
Talk-ee mailing list
Talk-ee@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ee

Re: [Talk-ca] Pertinence de lcn=yes pour le Québec

[Pierre Béland via Talk-ca]

Je trouve sensiblement la même chose- 8 099 chemins
-      90 relations
 Pour ce qui est de la clé lcn=yes sur les chemins, cela me semble aussi 
inutile.  On peut distinguer les réseaux plus importants (niveau local ou 
autre) en créant une relation regroupant divers segments.
Sans doute plusieurs contributeurs ne font que suivre la liste sans intervenir. 
Bonne occasion de commenter même brièvement ou indiquer simplement votre accord 
avec ceci.
Pour les révisions Route Verte peu nombreuses, je pense qu'il est possible de 
procéder dès maintenant.
Pour les révisions lcn sur les chemins, je suggère d'attendre une semaine ou 
deux pour donner le temps à d'autres contributeurs de réagir.
Pierre 

 

Le jeudi 3 octobre 2019 12 h 53 min 48 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le 
changement d’objet de la conversation. Le message original couvrant les autres 
sujets se trouve ici: 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html Afin 
de bien mesurer l’ampleur j’ai sorti ces données concernant l’utilisation du 
lcn=yes dans les chemins (ways) et network=lcn dans les relations pour le 
Québec. Je crois avoir bien circonscrit les données au Québec dans 
overpass-turbo. Si quelqu’un veut vérifier ces chiffres pour corroborer ma 
démarche. J’ai trouvé:   
   -  8106 chemins avec l’attribut lcn=yes présumé non pertinent puisque cet 
attribut serait réservé aux routes dans des relations. Ces attributs dans les 
chemins devraient alors être systématiquement enlevés. Une vérification 
régulière de la situation pourrait ensuite être faite pour éviter qu’il ne 
réapparaisse de la part de contributeurs non informés.   
  
   -  90 relations avec network=lcn. Il resterait à vérifier la pertinence des 
ces 90 relations après avoir défini ce qui est une route lcn pour le Québec 
puis, sur une certaine période, créer les relations qui correspondraient aux 
routes absentes.
 Ceci touche le travail passé de dizaines sinon centaines de contributeurs qui 
ont cartographié les pistes cyclables et déployé l’usage de lcn=yes. Comment 
les joindre pour avoir leur avis et implanter une nouvelle façon de faire?  Et 
comme le disait Pierre quels critères retenir pour définir ce qu’est une route 
lcn surtout avec la diversité des façons de faire dans les municipalités. En 
l’absence d’une structure provinciale pour avoir cette discussion est-ce qu’une 
discussion à 3 est  satisfaisante. Claude P.S. L’avis des autres contributeurs 
aux réseaux cyclables du Québec présents sur cette liste serait apprécié. From: 
Pierre Béland Sent: Tuesday, October 1, 2019 4:09 PMTo: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 Subject: Re: [Talk-ca] Carte velo CyclOSM et 
Référence Route Verte  Le wiki résume la réflexion à un certain moment donné et 
il faut être capable de le réviser si nécessaire. Tout comme pour le réseau 
routier, il y a place à l'interprétation lorsque nous hiérarchisons un réseau.  
Il faut lui donner du sens, et puis oui réduire le bruit avec tous les petits 
segments très locaux. 
 1- L’utilisation de lcn=yes
Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-at] Tirol, Regionale Fahrverbote werden zur Dauereinrichtung

[Johann Haag]

Ich hatte die Tiroler Fahrverbote bereits gemappt, in den Wirren eines
missglückten Reverts, sind diese aber wieder verloren gegangen. Nun sollten
diese Fahrverbote weiter bestand haben, wie gehen wir hier nun vor.

Grüße Johann Haag,
Ehrenamtlicher und unabhängiger Mapper aus St. Johann in Tirol
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[Johann Haag]

Die Angelegenheit ist ziemlich einfach.
Entscheidet Euch für eine der beiden Varianten, die Festlegung gilt dann für 
gesamt Österreich.
In Tirol und Vorarlberg genügt ein einfaches Revert, im Osten dann weg mit den 
Gemeinde Präfixen. Oder umgekehrt.
Ich bin da sehr aufgeschlossen.


Grüße Johann Haag

> Am 01.10.2019 um 18:48 schrieb PPete :
> 
> Mir ist aufgefallen, das kürzlich in Tirol und Vorarlberg die Namen vieler 
> Gemeinde- und Bezirksrelationen verändert werden. Z.b: 
> https://www.openstreetmap.org/changeset/75069032 
> 
> Ich weiß, dass das ein sehr ambivalent diskutiertes Thema ist, und es meines 
> Wissens nach dazu in Österreich keinen Konsens gibt, ob man z.b. die Wörter 
> "Gemeinde" und "Bezirk" in den name-Tag packt, in einen prefix-Tag oder 
> sonstwo hin. Auf jeden Fall erstellt diese Umbezeichung aus derzeitiger Sicht 
> keine Verbesserung der vorhanden Daten da und erzeugt ohne vorige Diskussion 
> und Übereinkunft im Forum oder in der Mailingliste sicherlich Spannungen in 
> der Communtiy.
> 
> Ich für mich würde z.b. eine Umbennung durch einen einzelnen Mapper ohne 
> vorige Abstimmung des über mehrere Jahre hinweg vereinheitlichten 
> Relationsschemas in Oberösterreich nicht für gut heißen.
> 
> ___
> 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-at] Mangelhafte Qualität des Users 1zu1

[Johann Haag]

in letzter Zeit ist mir qualitativ mangelhafte, aber umfangreiche
Mappingarbeit des sonst international Tätigen Users
https://www.openstreetmap.org/user/1zu1 in Österreich aufgefallen.
Ich habe versucht 1zu1 per Changeset Kommentar auf einige Probleme seiner
eingebrachten Arbeiten hinweisen, leder reagiert dieser auf keine Hinweise.
Wie sollen wir hier vorgehen. Ich schlage ein Revert vor.

Grüße Johann

OSM: https://www.openstreetmap.org/user/beautifulplaces
Mein Blog blog.hxg.at
Meine Real Identität: Johann Haag St. Johann in Tirol
Meine Mitwirkung in OSM, ehrenamtlich, unabhängig
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Maine leaf-off imagery?

[Kevin]

I use https://coast.noaa.gov/inventory/ quite a lot to see what elevation
products (usually looking for lidar) are available for any given area.

So LIDAR was flown in 2016 in the Bethel area.
https://coast.noaa.gov/dataviewer/#/lidar/search/where:ID=6264
There's an option to bulk download the raw laz files.  I'm curious what
your process is for incorporating the lidar into osm.

On Thu, Oct 3, 2019 at 12:40 PM Kevin Broderick 
wrote:

> Thanks for the responses.
>
> Unfortunately, the State of Maine LIDAR project doesn't yet have data
> available where I'm trying to map; in many cases, LIDAR would actually be
> preferable to even leaf-off-orthoimagery, as forest roads tend to stand out
> a lot better.
>
> The state regional orthoimagery is generally speaking, out-of-date
> compared to the other datasources available in id (particularly bing when
> not zoomed in all the way). Thanks for pointing out the NAIP, though, as
> that is definitely more recent than most and very helpful even if the
> resolution isn't ideal. Based on foliage coloration, it looks like fall
> flights, so it's a little better than midsummer at least.
>
> On Thu, Oct 3, 2019 at 11:57 AM Kevin  wrote:
>
>> Maine has some nice ortho imagery available through their arcgis
>> services..
>> https://gis.maine.gov/arcgis/rest/services/imageryBaseMapsEarthCover
>>
>> It looks like you'll want to look at the orthoRegional datasets.  You can
>> just browse what's available here...
>>
>> https://maine.maps.arcgis.com/apps/MapSeries/index.html?appid=56500882464149b3ae028b51665e5e56
>>
>>
>> I'm not sure how to add an image service to iD but it looks like it does
>> support WMS.
>>
>> Also it looks like NAIP was flown in the area in 2018.  Although NAIP
>> isn't typically leaf off or super high resolution, it may be of help.  The
>> USDA image service for the US can be found here.
>> https://gis.apfo.usda.gov/arcgis/rest/services
>>
>> On Wed, Oct 2, 2019 at 9:20 PM Kevin Broderick 
>> wrote:
>>
>>> Anyone have an ODbL-compatible source of leaf-off imagery for Maine, by
>>> any chance? I'm particularly interested in the area around Bethel, as I'm
>>> trying to update minor roadways, add buildings with driveways, etc.,
>>> and even switching between the various imagery available in id leaves a lot
>>> of questions unanswered. Leaf-off imagery would be incredibly helpful, the
>>> more so if it were actually recent.
>>>
>>> (Yes, I've been surveying where feasible, but I'm not about to start
>>> going up driveways to get building dimensions.)
>>>
>>> Many thanks.
>>>
>>> --
>>> Kevin Broderick
>>> k...@kevinbroderick.com
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-ca] Pertinence de lcn=yes pour le Québec

[Alouette955]

Bonjour,

J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le changement 
d’objet de la conversation.

Le message original couvrant les autres sujets se trouve ici: 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html

Afin de bien mesurer l’ampleur j’ai sorti ces données concernant l’utilisation 
du lcn=yes dans les chemins (ways) et network=lcn dans les relations pour le 
Québec.

Je crois avoir bien circonscrit les données au Québec dans overpass-turbo. Si 
quelqu’un veut vérifier ces chiffres pour corroborer ma démarche.

J’ai trouvé:
  a.. 8106 chemins avec l’attribut lcn=yes présumé non pertinent puisque cet 
attribut serait réservé aux routes dans des relations. Ces attributs dans les 
chemins devraient alors être systématiquement enlevés. Une vérification 
régulière de la situation pourrait ensuite être faite pour éviter qu’il ne 
réapparaisse de la part de contributeurs non informés.
   
  b.. 90 relations avec network=lcn. Il resterait à vérifier la pertinence des 
ces 90 relations après avoir défini ce qui est une route lcn pour le Québec 
puis, sur une certaine période, créer les relations qui correspondraient aux 
routes absentes.

Ceci touche le travail passé de dizaines sinon centaines de contributeurs qui 
ont cartographié les pistes cyclables et déployé l’usage de lcn=yes.

Comment les joindre pour avoir leur avis et implanter une nouvelle façon de 
faire? 

Et comme le disait Pierre quels critères retenir pour définir ce qu’est une 
route lcn surtout avec la diversité des façons de faire dans les municipalités.

En l’absence d’une structure provinciale pour avoir cette discussion est-ce 
qu’une discussion à 3 est  satisfaisante.

Claude

P.S. L’avis des autres contributeurs aux réseaux cyclables du Québec présents 
sur cette liste serait apprécié.

From: Pierre Béland 
Sent: Tuesday, October 1, 2019 4:09 PM
To: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 
Subject: Re: [Talk-ca] Carte velo CyclOSM et Référence Route Verte


Le wiki résume la réflexion à un certain moment donné et il faut être capable 
de le réviser si nécessaire. Tout comme pour le réseau routier, il y a place à 
l'interprétation lorsque nous hiérarchisons un réseau.  Il faut lui donner du 
sens, et puis oui réduire le bruit avec tous les petits segments très locaux. 


1- L’utilisation de lcn=yes


Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.


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

Re: [Talk-us] Maine leaf-off imagery?

[Kevin Broderick]

Thanks for the responses.

Unfortunately, the State of Maine LIDAR project doesn't yet have data
available where I'm trying to map; in many cases, LIDAR would actually be
preferable to even leaf-off-orthoimagery, as forest roads tend to stand out
a lot better.

The state regional orthoimagery is generally speaking, out-of-date compared
to the other datasources available in id (particularly bing when not zoomed
in all the way). Thanks for pointing out the NAIP, though, as that is
definitely more recent than most and very helpful even if the resolution
isn't ideal. Based on foliage coloration, it looks like fall flights, so
it's a little better than midsummer at least.

On Thu, Oct 3, 2019 at 11:57 AM Kevin  wrote:

> Maine has some nice ortho imagery available through their arcgis
> services..
> https://gis.maine.gov/arcgis/rest/services/imageryBaseMapsEarthCover
>
> It looks like you'll want to look at the orthoRegional datasets.  You can
> just browse what's available here...
>
> https://maine.maps.arcgis.com/apps/MapSeries/index.html?appid=56500882464149b3ae028b51665e5e56
>
>
> I'm not sure how to add an image service to iD but it looks like it does
> support WMS.
>
> Also it looks like NAIP was flown in the area in 2018.  Although NAIP
> isn't typically leaf off or super high resolution, it may be of help.  The
> USDA image service for the US can be found here.
> https://gis.apfo.usda.gov/arcgis/rest/services
>
> On Wed, Oct 2, 2019 at 9:20 PM Kevin Broderick 
> wrote:
>
>> Anyone have an ODbL-compatible source of leaf-off imagery for Maine, by
>> any chance? I'm particularly interested in the area around Bethel, as I'm
>> trying to update minor roadways, add buildings with driveways, etc.,
>> and even switching between the various imagery available in id leaves a lot
>> of questions unanswered. Leaf-off imagery would be incredibly helpful, the
>> more so if it were actually recent.
>>
>> (Yes, I've been surveying where feasible, but I'm not about to start
>> going up driveways to get building dimensions.)
>>
>> Many thanks.
>>
>> --
>> Kevin Broderick
>> k...@kevinbroderick.com
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>

-- 
Kevin Broderick
k...@kevinbroderick.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-ja] 自動車専用の道路のタグ付け

[kkondo]

こんにちはxyzxyz2です。

この小田原箱根道路はタグ付けが簡単ではなさそうですね：

上りは、Google Street View で (139.1194, 35.2372) 
地点付近の標識で見てみますと（現時点）、「この先900m」のトンネル（の出口当たり）までに左車線へ変更すれば、「小田原市街」（風祭）へ出られます（路面の表示も）。これに反して御引用の記事のように右車線のまま走行すると西湘バイパス（自動車専用道路）へ進入してしまう作りのようです。
・御引用の記事： 
「警官たちも信じてくれなかったが、原付で通行禁止の案内も無いのに自動車専用道に吸い込まれてしまった。覆面パトカーに護衛されながら走ったのは生まれて初めて…。」 
https://twinavi.jp/topics/tidbits/55be1769-80c8-4859-a295-05ac5546ec81 


また下りは、「125cc以下の二輪車は通行して欲しくない」ということなのですね。


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

Re: [OSM-talk-fr] Moulinette pour convertir codes Insee en GPS > GPX ?

[Shohreh]

cquest wrote
> De plus, pour moi, utiliser une API* pour résoudre ce type de problème est
> quand même une aberration... il s'agit de faire un simple JOIN entre 2
> fichiers, trucs que je ferai localement en ligne de commande avec csvjoin
> de csvkit.

Merci pour le CSV avec les coordonnées des villes.

Le "3190Moulins", c'est parce que je n'avais pas modifié la colonne dans
LibreOffice pour qu'elle prenne du texte et non du numérique, et le 0 a
giclé :-)

All is well.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-us] Maine leaf-off imagery?

[Kevin]

Maine has some nice ortho imagery available through their arcgis services..
https://gis.maine.gov/arcgis/rest/services/imageryBaseMapsEarthCover

It looks like you'll want to look at the orthoRegional datasets.  You can
just browse what's available here...
https://maine.maps.arcgis.com/apps/MapSeries/index.html?appid=56500882464149b3ae028b51665e5e56


I'm not sure how to add an image service to iD but it looks like it does
support WMS.

Also it looks like NAIP was flown in the area in 2018.  Although NAIP isn't
typically leaf off or super high resolution, it may be of help.  The USDA
image service for the US can be found here.
https://gis.apfo.usda.gov/arcgis/rest/services

On Wed, Oct 2, 2019 at 9:20 PM Kevin Broderick 
wrote:

> Anyone have an ODbL-compatible source of leaf-off imagery for Maine, by
> any chance? I'm particularly interested in the area around Bethel, as I'm
> trying to update minor roadways, add buildings with driveways, etc.,
> and even switching between the various imagery available in id leaves a lot
> of questions unanswered. Leaf-off imagery would be incredibly helpful, the
> more so if it were actually recent.
>
> (Yes, I've been surveying where feasible, but I'm not about to start going
> up driveways to get building dimensions.)
>
> Many thanks.
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> 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-ca] Postcodes in Canada

[john whelan]

Canadian Postal Codes in urban areas are blocks of roughly 50 buildings
which makes them extremely interesting to use for GIS studies.  Average
income etc.

Both in the UK and Canada many people would rather type in a 6 character
code than a street address with city when looking for directions to a
location.  In the UK postcodes where restricted to a street which meant
when computer storage was expensive we used something called a prem code
which was the building number followed by the postcode and generated the
full address when required.  Canadian postcodes can spam different streets
especially in areas served by supermail boxes.

If I use  the example of my own address.  The house was built in the City
of Cumberland, but my postal address was Navan.  Then Canada Post changed
the postal address to Orleans which is interesting as Orleans does not
exist as a municipality.  Apparentyl there are one or two other places in
Canada that Canada Post doesn't use the municipality name in the postal
address.  Currently it is in the City of Ottawa so some mail gets addressed
Orleans and some Ottawa.  I had an elderly aunt who always addressed my
Christmas card to Navan and included the postcode until she died and each
year the post office would attach a sticker saying the postal address was
wrong.  The post code remains the same over all the changes.

So yes a postcode can change but from time to time they are more stable
than the official postal address.

As long as one address contains the postcode then Nominatim will find it
which means it can be used for directions.  You might be 30 buildings away
but you are in the right general area so I think adding them as part of a
street address is of value.

Cheerio John



On Thu, 3 Oct 2019 at 11:24, Justin Tracey  wrote:

> In the US, ZIP Codes (the US postal code equivalent) are frequently
> emphasized to not correspond to geographic locations, but sets of
> addresses. Of course they frequently cluster according to geography (and
> the prefixes are indeed assigned to states and regions within the
> state), and are often used as stand-ins, but you can't make assumptions
> about continuity or proximity for the addresses they correspond with.
> Even though I can't find it explicitly worded that way (i.e., "post
> codes are address sets, not locations"), it seems to be the same
> situation here. Given that, the most "correct" thing to do would be
> tagging postal codes in addresses, and not as distinct entities.
>
> The Canada Post website has a tool to lookup the postal code for a
> particular address, so if it were released, wouldn't the data they use
> to supply that information be good enough for this? It doesn't quite
> solve people trying to navigate "to" a particular postal code, but it
> seems like that's an ambiguous request anyway.
>
>  - Justin
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Postcodes in Canada

[Justin Tracey]

In the US, ZIP Codes (the US postal code equivalent) are frequently
emphasized to not correspond to geographic locations, but sets of
addresses. Of course they frequently cluster according to geography (and
the prefixes are indeed assigned to states and regions within the
state), and are often used as stand-ins, but you can't make assumptions
about continuity or proximity for the addresses they correspond with.
Even though I can't find it explicitly worded that way (i.e., "post
codes are address sets, not locations"), it seems to be the same
situation here. Given that, the most "correct" thing to do would be
tagging postal codes in addresses, and not as distinct entities.

The Canada Post website has a tool to lookup the postal code for a
particular address, so if it were released, wouldn't the data they use
to supply that information be good enough for this? It doesn't quite
solve people trying to navigate "to" a particular postal code, but it
seems like that's an ambiguous request anyway.

 - Justin

On 2019-10-02 8:53 p.m., Kevin Farrugia wrote:
> I don't want to rain on the postal code party, and maybe I'm a little
> jaded from using the data, but I use the Postal Code Conversion File
> (PCCF) from Statistics Canada (who get it from Canada Post) at work. 
> In general I would say that the postal code points are in mediocre shape.
>
> Some things I've noticed about the data and postal codes in general:
> * There is usually one postal code point per postal code, although
> there are cases where there can be several points for a postal code. 
> For example, with some postal codes, if you were to make them
> polygons, would generate multiple polygons that are intersected by
> other postal codes.
> * Postal codes, especially rural ones, pop in and out of existence and
> so are a little harder to track and are less permanent than addresses.
> * Postal codes will sometimes jump from one side of a road (even
> municipality) between years as they try to improve accuracy.
> I would check out the Limitations section if you'd like to see
> more: 
> https://www.canadapost.ca/cpc/assets/cpc/uploads/files/marketing/2017-postal-code-conversion-file-reference-guide-en.pdf
>
> Forward Sortation Areas do exist as open data through Statistics
> Canada - StatsCan generates these FSA polygons based on respondents of
> the Census.  There are two limitations to this dataset on which I
> would advise against importing it into OSM:
> 1) Since businesses do not respond to the Census, they generally do
> not have FSAs for large industrial areas.  These areas are covered by
> the nearest FSA that they know about/can define, but this can also
> cause some movements of boundaries from Census to Census.
> 2) Because postal codes are created for the purpose of mail sortation
> and delivery, the FSA boundaries StatsCan is able to create are not exact.
> Here's the reference document if you're
> interested: 
> https://www150.statcan.gc.ca/n1/pub/92-179-g/92-179-g2016001-eng.htm
>
> If at some point they did release it as open data, it might be decent
> enough for the purposes of general geocoding in OSM, I just don't want
> people to think it's as well maintained and reliable as some other
> types of government data.
>
> -Kevin (Kevo)
>
>
> On Wed, 2 Oct 2019 at 20:39, James  > wrote:
>
> funny you should mention geocoder.ca  
>
> The owner of that website was sued by Canada Post because he was
> crowd sourcing postal codes. Just recently (2 ish years ago?) they
> dropped the lawsuit because they knew they didnt have a case(He
> came to the Ottawa meetups a couple of times)
>
> On Wed., Oct. 2, 2019, 8:08 p.m. Jarek Piórkowski,
> mailto:ja...@piorkowski.ca>> wrote:
>
> Yeah, Canada Post currently considers postal codes their
> commercial
> data. Crowd-sourcing all or a substantial amount of full codes
> seems
> infeasible. Crowd-sourcing the forward sortation areas (the
> first A1A)
> seems difficult since verifiability is going to be a problem
> especially around the edges of the areas.
>
> The website OpenStreetMap.org returns results for some postal
> codes
> from a third-party database https://geocoder.ca/?terms=1 which
> is not
> ODbL-compatible either.
>
> Partial mapping is causing some problems with tools like Nominatim
> that attach the nearest tagged postcode to search results, often
> resulting in improper postal codes for reverse address lookups,
> however that is arguably a tooling problem and not an OSM
> problem per
> se.
>
> This isn't going to be pretty until Canada Post is persuaded
> to free
> the data. Call your MP, everybody.
>
> --Jarek
>
> On Wed, 2 Oct 2019 at 17:38, john whelan
> mailto:jwhelan0...@gmail.com>> wrote:
> >
> > 

Re: [Talk-de] Fragen, Anregung eines Neulings

[Florian Lohoff]

On Wed, Oct 02, 2019 at 02:58:16PM +0200, Roland Olbricht wrote:
> Sehr geehrter Herr Mehl,

> nach den Routing-Regeln
> https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua
> schaut, dann findet man, dass
> 
> avoid = Set {
> [...]
>   'construction',
>   'proposed'
> },
> 
> d.h. es wird in der Tat die Route von routing.openstreetmap.de nicht
> genutzt, weil "construction=yes" gesetzt ist. Hier wäre jetzt die
> Einschätzung gefragt, ob das Tag "construction=yes" gerechfertigt ist.
> Aus der Erfahrung und Beschreibung auf
> https://wiki.openstreetmap.org/wiki/DE:Key:construction
> liest man, dass das Tag nicht verwendet werden sollte (sondern
> "highway=construction" + "construction=motorway", wenn und nur wenn die
> Fahrbahn unbefahrbar ist).

Meist sind die construction=XYZ überbleibsel von einer "Ehemaligen
Baustelle". D.h. das highway= tag wird korrigiert wenn die Baustelle
durch ist, aber jemand vergisst das construction=XYZ tag. Damit
ist das für OSRM nicht nutzbar, in der Karte sieht man das aber
nicht weil highway beim rendering über construction=XYZ steht.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-ie] Duplicate townland nodes

[Mark O'Donovan]

Thanks.

If I don't hear any dissenting opinions i'll clean a few of these next week.

Unfortunately the openstreetmap.org map will be a bit bare afterwards.

Regards,
Mark

On 03/10/2019 14:48, moltonel 3x Combo wrote:

On 03/10/2019, Mark O'Donovan  wrote:

Hi,

The two items below have the same tags and appear twice in the FDroid
version of Maps.me.

https://www.openstreetmap.org/relation/5910219
https://www.openstreetmap.org/node/3524289126

locality : townland
name : Knockrobin
place : locality


In these situations should the node be removed?


Yes. One OSM object for one real-world feature.

The node was created before the relation. It's pretty common to
"upgrade" a node to an area once more time or information is
available, and sometimes we forget to remove the original node.

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



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

Re: [OSM-talk-ie] Duplicate townland nodes

[moltonel 3x Combo]

On 03/10/2019, Mark O'Donovan  wrote:
> Hi,
>
> The two items below have the same tags and appear twice in the FDroid
> version of Maps.me.
>
> https://www.openstreetmap.org/relation/5910219
> https://www.openstreetmap.org/node/3524289126
>
> locality : townland
> name : Knockrobin
> place : locality
>
>
> In these situations should the node be removed?

Yes. One OSM object for one real-world feature.

The node was created before the relation. It's pretty common to
"upgrade" a node to an area once more time or information is
available, and sometimes we forget to remove the original node.

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

[OSM-talk-ie] Duplicate townland nodes

[Mark O'Donovan]

Hi,

The two items below have the same tags and appear twice in the FDroid 
version of Maps.me.


https://www.openstreetmap.org/relation/5910219
https://www.openstreetmap.org/node/3524289126

locality : townland
name : Knockrobin
place : locality


In these situations should the node be removed?

Thanks,
Mark

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

Re: [OSM-talk-fr] Rapprochement OSM/Fantoir : données cadastre obsolètes ?

[Brice MALLET]

Le 30/09/2019 à 22:40, Vincent de Château-Thierry a écrit :

Merci pour votre patience


Merci pour le travail réalisé / encore à réaliser.

--
Britzz

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

Re: [OSM-talk-fr] effet SNT / quelle contribution ?

[Brice MALLET]

Le 30/09/2019 à 17:58, Cédric Frayssinet a écrit :
> prévu de faire contribuer les élèves mais selon les classes, ce sera 
peut-être différent :

  * carto-partie ciblée autour du lycée,
  * repérer des contributions dans les quartiers des élèves et les faire
avec moi lors des séances en classe,
  * autre ?


Et une sorte de jeu de piste en identifiant les "Notes de carte" ou les 
fixme qui demandent vérification sur le terrain ?



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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[Andrea Musuruane]

Ciao,
 non è indicata la URL della pagina dove si trova il dato sorgente (il
link è http://tbd/).

Puoi aggiornare per favore?

Grazie,

Andrea


On Wed, Oct 2, 2019 at 10:45 AM Cascafico Giovanni 
wrote:

> Ciao Lista,
>
> ho abbozzato una wiki [1] in inglese per l'import regione Friuli
> Venezia Giulia del dataset Confartigianato delle attività economiche.
> Commentate pure alla sezione discussione [2] per strafalcioni,
> chiarimenti, suggerimenti.
>
> I dettagli sono ancora in sviluppo. Se il pilota gelatieri e
> pasticceri va bene, proseguirò con le altre attività.
>
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlimentareFVG
> [2]
> https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/AlimentareFVG
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[cascafico]

voschix wrote
> Una tipica pasticceria qua (Nordest) offre questi servizi:
> caffè (amenity=cafe)
> bevande non alcoliche (acqua, cola, spremute, ...)
> alcolici (birra, vino, liquori, ...)
> ciocolatini (tipicamente asporto)
> brioches (consumo sul posto)
> pastine  (consumo sul posto e asporto)
> semifreddi (tipicamente asporto)
> caramelle
> 
> Non tutti hanno la produzione allo stesso posto del locale
> Pochi vendono anche pane
> Pochi vendono anche gelato (consumo sul posto)
> Poi una distinzione importante per l'utente: alcuni hanno tavoli per il
> consumo, altri no (solo vendita).
> E probabilmente tanti altri varianti e combinazioni
> 
> Nella fase di conflation come gestiamo l'informazione pre-esistente in OSM
> su questi punti?  E quali di queste dettagli sono presenti nel dataset.

Nell'import esiste una fase che si chiama audit: vi invito ad esplorare
alcune categorie che ho preparato [1]. L'audit per le gelaterie [2] l'ho
appena concluso da solo; la fusione delle info del dataset con quelle di osm
non ha dato molti problemi: solo alcuni cafe e pastry preesistenti che,
terminato l'audit, ho risolto via JOSM in locale *prima* dell'import.
Il file candidato all'import è ice_cream.osm ed è linkato nella tabella del
paragrafo Progress [3]

Il revisore (qualunque utente OSM loggato),  può segnalare nel fixme
problemi della versione OSM, della versione dataset, problemi risolvibili
semplicemente, oppure problemi da lasciare nel tag fixme.


[1] http://audit.osmz.ru/
[2] http://audit.osmz.ru/project/FVG-ice_cream/
[3]
https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlimentareFVG#Progress



-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[OSM-talk-nl] JOSM plugin "Ga naar" ontwikkeling.

[Allroads]

Hallo,

Er is ondertussen veel data, die we mogen gebruiken voor mapping/tagging in 
Openstreetmap.
Data, waarvoor we als Openstreetmap Nederland afspraken hebben gemaakt.
Deze data is vaak in layer vorm te zien op een website, een website met in de 
url de geografisch coördinaten en zoomniveau.
Binnen de Openstreetmap community zijn ook enkele van deze sites ontwikkeld. Om 
inzicht te krijgen. Hoe eigen Openstreetmap data is getagd. 
Voorbeeld: zone 30 controle, of een gebied sluitend is.
http://mijndev.openstreetmap.nl/~marczoutendijk/openpoimap/nlvb/?map=snelheid=17=51.57365=3.70426=B0FTTFFF
of
http://mijndev.openstreetmap.nl/~ligfietser/fiets/?map=bugs=17=52.34174=4.9159=B00TTTFFF
(van deze sites kunnen we wel naar JOSM, maar niet vanuit JOSM naar de site.)

Wanneer alles makkelijker bereikbaar is, het in de lijst staat als controle 
mogelijkheid, is er makkelijker te communiceren (copy/paste permalinks) en de 
kwaliteit van de data te verbeteren.
En kan je meer respons verwachten!

Wanneer we aan het editen zijn, wil je wel eens snel naar een site, op de 
ingezoomde plaats.

Als voorbeeld:
We mogen nu BGT gebruiken, als layer BGT omtrekgericht in JOSM.
Je werkt op lokaal niveau, ziet dat er iets niet klopt en wil naar “Verbeter de 
kaart” website op locatie om een melding te maken.
Nu moet je vele stappen nemen van/naar en inzoomen. Melding maken.
https://www.verbeterdekaart.nl/#?geometry.x=16.5185=451931.46324746=3

Wat ik mij voor stel is.
Een node in JOSM selecteren, de knop in taakbalk “Ga naar” de website kiezen, 
waar je naar toe wilt.
Een Nederlandse lijst of eigen lijst, met websites om naar toe te gaan.

De plugin: “Ga naar” of wel “Go to”.

Wie zou willen helpen om dit tot stand te brengen? Participeren in de 
ontwikkeling, kennis inbrengen.
Interactie tot stand brengen van burger (vrijwilliger Openstreetmap) naar 
Overheid. Win/win.
Wellicht kan de Overheid, ook een taak op zich nemen. Meer meldingen is betere 
data, vooral ook omdat de Openstreetmap mapper zeer lokaal/ingezoomd werkt en 
vergelijkt.
De suggestie is al bij “Verbeter de kaart” neergelegd. Financiering Kadaster is 
moeilijk, prioriteiten. De API is mij bekend. Naar website, korte en simpele 
stap zonder API?
Wellicht zijn er fondsen, financiering vormen, die dit mogelijk kunnen maken. 
Wie ziet daar mogelijkheden of zit aan het roer?

Wat denken jullie van het plan en de uitvoerbaarheid?


Met vriendelijke groet,
Allroads.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles

[Rpnpif]

Le  2 octobre 2019, Christian Quest a écrit :

> Le but de cette demo est surtout de trouver un lieu et de le montrer
> ensuite sur la carte, la présentation de ce qui ressemble à une adresse est
> très accessoire ;)
> C'est le mix adresses + POI qui n'est pas évident, ainsi que la volumétrie
> globale:
> - 16.4 millions d'adresses BANO
> - 4 millions de lieux-dits BANO
> - 2.8 millions de POI OSM
> - 68000 geonames
> 
> BANO n'est pas totalement à jour sur les fusions de communes, c'est pour
> cela que ce n'est pas forcément bien raccord.
> 
> Pour les codes postaux infra-communaux, on peut les cartographier dans OSM
> (boundary=postal_code si ma mémoire est bonne), les scripts de BANO en
> tiennent compte. C'est utilisé par exemple sur 75016/75116 ou 94100/94210.
> 
> Pour les communes nouvelles, il faut peut être revoir quelques trucs...
> 
> Et puis... La Poste ? Elle nous casse les pieds, qu'elle continue comme ça
> et le courrier se réduira encore plus vite vers le zéro.
> Ses bases contiennent les anciens noms de commune et peuvent très bien y
> distribuer le courrier si elle en a envie (ce qui est à se demander).

Merci pour ces explications.

Donc à réfléchir dans OSM sur les communes nouvelles.

Et on va tenter quand j'aurai un moment de bien faire le zonage du code
postal pour Angers par exemple.

HS : mais pourquoi le gouvernement complique encore en ajoutant des
règles électorales spécifiques aux communes nouvelles. Les fusions qui
devait simplifier, compliquent plus en créant une institution à part,
donc pas seulement dans OSM.

-- 
Alain Rpnpif

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

Re: [Talk-GB] Rights of way vs. tracks

[Steve Doerr]

On 29/09/2019 21:58, Edward Bainton wrote:
> running from 511,025.344 298,855.444 Meters to 510,856.672 
298,723.814 Meters

>
> I don't recognise that coordinate system: is it any help for OSM?

It's a millimetre-precision version of the Ordnance Survey grid 
reference. For conversion, see e.g. 
http://streetmap.co.uk/idgc.srf?x=511025.344=298855.444



--

Steve




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

[OSM-talk-nl] JOSM plugin "Ga naar" ontwikkeling.

[Allroads]

Hallo,

Er is ondertussen veel data, die we mogen gebruiken voor mapping/tagging in 
Openstreetmap.
Data, waarvoor we als Openstreetmap Nederland afspraken hebben gemaakt.
Deze data is vaak in layer vorm te zien op een website, een website met in de 
url de geografisch coördinaten en zoomniveau.
Binnen de Openstreetmap community zijn ook enkele van deze sites ontwikkeld. Om 
inzicht te krijgen. Hoe eigen Openstreetmap data is getagd. 
Voorbeeld: zone 30 controle, of een gebied sluitend is.
http://mijndev.openstreetmap.nl/~marczoutendijk/openpoimap/nlvb/?map=snelheid=17=51.57365=3.70426=B0FTTFFF

Wanneer alles makkelijker bereikbaar is, het in de lijst staat als controle 
mogelijkheid, is er makkelijker te communiceren en de kwaliteit van de data te 
verbeteren.
En kan je meer respons verwachten!

Wanneer we aan het editen zijn, wil je wel eens snel naar een site, op de 
ingezoomde plaats.

Als voorbeeld:
We mogen nu BGT gebruiken, als layer BGT omtrekgericht in JOSM.
Je werkt op lokaal niveau, ziet dat er iets niet klopt en wil naar “Verbeter de 
kaart” website op locatie om een melding te maken.
Nu moet je vele stappen nemen van/naar en inzoomen. Melding maken.
https://www.verbeterdekaart.nl/#?geometry.x=16.5185=451931.46324746=3

Wat ik mij voor stel is.
Een node in JOSM selecteren, de knop in taakbalk “Ga naar” de website kiezen, 
waar je naar toe wilt.
Een Nederlandse lijst of eigen lijst, met websites om naar toe te gaan.

De plugin: “Ga naar”.

Wie zou willen helpen om dit tot stand te brengen? Participeren in de 
ontwikkeling, kennis inbrengen.
Interactie tot stand brengen van burger (vrijwilliger Openstreetmap) naar 
Overheid. Win/win.
Wellicht kan de Overheid, ook een taak op zich nemen. Meer meldingen is betere 
data, vooral ook omdat de Openstreetmap mapper zeer lokaal/ingezoomd werkt en 
vergelijkt.
De suggestie is al bij “Verbeter de kaart” neergelegd. Financiering Kadaster is 
moeilijk, prioriteiten. De API is mij bekend. Naar website, korte en simpele 
stap zonder API?
Wellicht zijn er fondsen, financiering vormen, die dit mogelijk kunnen maken. 
Wie ziet daar mogelijkheden of zit aan het roer?

Wat denken jullie van het plan en de uitvoerbaarheid?


Met vriendelijke groet,
Allroads.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[Martin Koppenhoefer]

Am Do., 3. Okt. 2019 um 11:29 Uhr schrieb cascafico :

> In base a questa ed altre proposte di dettagliare,  mi pare di capire che
> un
> processo automatico di tagging sia da escludere. In tal caso la possibilità
> è di inserire una descrizione più specifica (colonna ATTIVITA') nel tag
> description, tale da poter procedere con affinamento dopo l'import.




-1, se ci sono delle cose da aggiustare va fatto prima dell'import, non
dopo.

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

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[various]

Moment, so sehr ich dem Mapper gegenüber kritisch bin, es gehört NICHT 
revertiert, nur weil es von ihm kommt und er stur und unverbesserlich ist.
Wenn die Änderungen konkret falsch ist, dann gehört revertiert. Wenn es 
Diskussionsbedarf ob seiner Änderungen gibt, auch. Dann aber ab in den 
Changeset und wenn er da unverbesserlich ist und einfach weitermacht, bevor der 
Fall geklärt ist, dann gehört gegebenenfalls revertiert oder eine 0-Tage-Sperre 
verhängt um ihn zur Diskussion zu zwingen. 

Im Forum gibt es 3 Threads dazu, wobei 2 fälschlicherweise aufgemacht wurden, 
von alt nach neu:
https://forum.openstreetmap.org/viewtopic.php?id=64985
https://forum.openstreetmap.org/viewtopic.php?id=67494
https://forum.openstreetmap.org/viewtopic.php?id=67555

Jetzt behauptet er selbst allerdings auf seinem Blog, dass er im Forum immer 
noch gesperrt ist (müsste ja aufgehoben sein) und, dass er ja auf der 
Mailingliste (die er beharrlich ignoranterweise als "Forum" bezeichnet) 
zensiert wird. 

> Kevin Kofler  hat am 3. Oktober 2019 um 11:40 
> geschrieben:
> 
> 
> PPete wrote:
> > Der Mapper "beautifulplaces", welcher die kürzlichen Änderungen in Tirol
> > und Vorarlberg durchgeführt hat,
> 
> Ach, der schon wieder!
> 
> Dann bitte die Änderungen sofort reverten, jegliche Diskussion mit diesem 
> Mapper ist sinnlos, und in dem Fall kann es sich auch unmöglich um ein 
> Versehen handeln.
> 
> Kevin Kofler
> 
> 
> ___
> 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-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[Kevin Kofler]

PPete wrote:
> Der Mapper "beautifulplaces", welcher die kürzlichen Änderungen in Tirol
> und Vorarlberg durchgeführt hat,

Ach, der schon wieder!

Dann bitte die Änderungen sofort reverten, jegliche Diskussion mit diesem 
Mapper ist sinnlos, und in dem Fall kann es sich auch unmöglich um ein 
Versehen handeln.

Kevin Kofler


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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[cascafico]

In base a questa ed altre proposte di dettagliare,  mi pare di capire che un
processo automatico di tagging sia da escludere. In tal caso la possibilità
è di inserire una descrizione più specifica (colonna ATTIVITA') nel tag
description, tale da poter procedere con affinamento dopo l'import.







-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-ca] Postcodes in Canada

[James]

>For example  if K4A 1M7 exists in the map then it would be reasonable to
assume that K4A 1M6 - 1M1 should also exist so could be looked for.

Not necessarily. The first three characters are province, region
indicators. The last three are based on Canada Post's routes/delivery
zones. They create new ones all the time and probably not sequentially so
people need to subscribe to their shitty 5000$/year service

On Thu., Oct. 3, 2019, 12:23 a.m. Kyle Nuttall, 
wrote:

> I've found a good resource to use is a business website. Particularly a
> store with multiple locations, a mall directory, or a BIA. They have
> several postal codes that are associated with their respective addresses.
>
> Unfortunately it does require manual work (or you could pair a scrapper
> with a geocoder to do the tedious part) but given there is no available
> datasets we're licenced to use currently, it's the only public resource I
> know of where you can get pockets of postal codes.
>
> As more and more get added, the zones will begin to reflect their true
> shape more accurately and it'll be easier to extrapolate.
>
> I know it's not the best answer but any bit helps I suppose.
>
> On Oct. 2, 2019 21:33, John Whelan  wrote:
>
> I had long discussions with Canada Post about postcodes years ago.  I was
> working with Treasury Board standards group at the time looking at
> addressing standards and I'm very aware of the limitations.
>
> Rural post codes are very definitely an issue and not all postcodes used
> by Stats Canada and other government departments for example are physical
> locations.
>
> Open Data would be nice but realistically it isn't going to happen in the
> short term.
>
> Having said that what is doable is spotting postcodes that do exist but
> are not in OpenStreetMap then tagging a building with an address that
> includes a postcode in that postcode.
>
> For example  if K4A 1M7 exists in the map then it would be reasonable to
> assume that K4A 1M6 - 1M1 should also exist so could be looked for.
>
> Cobourg is an example where there are far fewer postcodes than one might
> like to see.
>
> Cheerio John
>
>
>
> Kevin Farrugia wrote on 2019-10-02 8:53 PM:
>
> I don't want to rain on the postal code party, and maybe I'm a little
> jaded from using the data, but I use the Postal Code Conversion File (PCCF)
> from Statistics Canada (who get it from Canada Post) at work.  In general I
> would say that the postal code points are in mediocre shape.
>
> Some things I've noticed about the data and postal codes in general:
> * There is usually one postal code point per postal code, although there
> are cases where there can be several points for a postal code.  For
> example, with some postal codes, if you were to make them polygons, would
> generate multiple polygons that are intersected by other postal codes.
> * Postal codes, especially rural ones, pop in and out of existence and so
> are a little harder to track and are less permanent than addresses.
> * Postal codes will sometimes jump from one side of a road (even
> municipality) between years as they try to improve accuracy.
> I would check out the Limitations section if you'd like to see more:
> https://www.canadapost.ca/cpc/assets/cpc/uploads/files/marketing/2017-postal-code-conversion-file-reference-guide-en.pdf
>
> Forward Sortation Areas do exist as open data through Statistics Canada -
> StatsCan generates these FSA polygons based on respondents of the Census.
> There are two limitations to this dataset on which I would advise against
> importing it into OSM:
> 1) Since businesses do not respond to the Census, they generally do not
> have FSAs for large industrial areas.  These areas are covered by the
> nearest FSA that they know about/can define, but this can also cause some
> movements of boundaries from Census to Census.
> 2) Because postal codes are created for the purpose of mail sortation and
> delivery, the FSA boundaries StatsCan is able to create are not exact.
> Here's the reference document if you're interested:
> https://www150.statcan.gc.ca/n1/pub/92-179-g/92-179-g2016001-eng.htm
>
> If at some point they did release it as open data, it might be decent
> enough for the purposes of general geocoding in OSM, I just don't want
> people to think it's as well maintained and reliable as some other types of
> government data.
>
> -Kevin (Kevo)
>
>
> On Wed, 2 Oct 2019 at 20:39, James  wrote:
>
> funny you should mention geocoder.ca
>
> The owner of that website was sued by Canada Post because he was crowd
> sourcing postal codes. Just recently (2 ish years ago?) they dropped the
> lawsuit because they knew they didnt have a case(He came to the Ottawa
> meetups a couple of times)
>
> On Wed., Oct. 2, 2019, 8:08 p.m. Jarek Piórkowski, 
> wrote:
>
> Yeah, Canada Post currently considers postal codes their commercial
> data. Crowd-sourcing all or a substantial amount of full codes seems
> infeasible. Crowd-sourcing the forward sortation areas (the first A1A)
> 

Re: [OSM-talk] EuroVelo routes are out of date

[Maarten Deen]

On 2019-10-03 10:55, Richard Fairhurst wrote:

Maarten Deen wrote:

Is it an idea to create some kind of ticketing system for this?


I think we already have this:

- create notes on osm.org, including the word "eurovelo"
- search for "eurovelo" on https://ent8r.github.io/NotesReview/


Great, if only it was used like that a bit more...

Regards,
Maarten

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

Re: [OSM-talk] EuroVelo routes are out of date

[Maarten Deen]

On 2019-10-03 10:27, Richard Fairhurst wrote:

EuroVelo routes are not in a great state in OSM. Many of them appear
to have been armchaired years ago when routes were "in development",
and not updated since to reflect the correct route.

A handful of examples:



…and there are lots more.


I'm sure I'm not saying anything new when I say that this is a general 
problem with routes in OSM.


Is it an idea to create some kind of ticketing system for this? Maybe 
put this all in Trac? Because someone who notices this may not always be 
someone who can check it. And you give a few examples now, but leave out 
the lots more that may be close to where other people can check.


Regards,
Maarten

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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[cascafico]

voschix wrote
> Ho guardato shop=pastry nel wiki e vedo (con orrore) il suggerimento di
> utilizzare due nodi nel caso che uno stabilimento è shop=pastry e
> shop=bakery. C'è anche il suggerimento di mappare solo l'attività
> prevalente.
> Penso che prima di fare un import di rivedere il mapping e aggiornare le
> varie pagine wiki.
> In più ho paura che anche i dati ufficiali (che volgiamo importare)
> soffrono della stessa problematica.

Per alimentare il tuo orrore, ho notato anche che le gastronomie (deli?)
sono contenute nella stessa categoria di pizza al taglio e kebab. Insomma
c'è abbastanza promiscuità.

Quello che si può fare è suddividere la categoria standard ATECO della
colonna "Mestiere", in base alle informazioni non standardizzate della
colonna ATTIVITA' (compilata in formato presumo libero dal gestore)



-

--
cascafico.altervista.org
twitter.com/cascafico
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[Martin Koppenhoefer]

Am Do., 3. Okt. 2019 um 10:42 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
>
>> Non tutti hanno la produzione allo stesso posto del locale
>> Pochi vendono anche pane
>>
>


dimenticavo, per distinguere la produzione propria da rivenditori, c'è la
possibilità di aggiungere il tag "craft" con apposito valore (pasticciere,
panettiere, ecc.). Per descrivere meglio il tipo di forno, c'è anche
oven=wood_fired e oven=electrical

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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[Martin Koppenhoefer]

Am Do., 3. Okt. 2019 um 10:20 Uhr schrieb Volker Schmidt :

> Vorrei sollevare una domanda dal punto di vista utente finale:
>
> Una tipica pasticceria qua (Nordest) offre questi servizi:
> caffè (amenity=cafe)
> bevande non alcoliche (acqua, cola, spremute, ...)
> alcolici (birra, vino, liquori, ...)
> ciocolatini (tipicamente asporto)
> brioches (consumo sul posto)
> pastine  (consumo sul posto e asporto)
> semifreddi (tipicamente asporto)
> caramelle
>
>

amenity=cafe (che comprende anche la vendita di pasti, bibite, alcolici,
torte, brioches, semifreddi, ecc.)



> Non tutti hanno la produzione allo stesso posto del locale
> Pochi vendono anche pane
>


shop=bakery
oppure
shop=pastry




> Pochi vendono anche gelato (consumo sul posto)
>


da capire cosa prevale, se si chiama "pasticceria gelateria" hai
l'imbarazzo della scelta, io metterei l'altra cosa come proprietà, per
esempio shop=pastry, sells:ice_cream=yes/industrial/artisanal
(usato poco), oppure ice_cream=yes/artisanal/industrial (usato molto di più
ma meno chiaro). In generale le gelaterie sono una sottospecie di
pasticceria.





> Poi una distinzione importante per l'utente: alcuni hanno tavoli per il
> consumo, altri no (solo vendita).
> E probabilmente tanti altri varianti e combinazioni
>


si, la mia proposta è di distinguere con
shop e amenity
shop se si tratta di solo asporto (vale anche per pizza al taglio). Il buon
amenity=ice_cream, usato più di tutto, non è chiaro a questo riguardo.
2 288
*shop* 
*ice_cream* 
26 439
*amenity* 
*ice_cream* 

11 489
*cuisine* 
*ice_cream* 


invece quando si tratta di una gelateria con servizio a tavola,
amenity=cafe con cuisine=ice_cream
(gli italiani aprono questi in Germania, ma qui non si trovano, oppure
poco). Questa tipologia di negozio spesso vende sia in asporto (cornetti e
coppette) che da consumarsi al tavolo (spesso vendono coppe grandi con
gelato e frutta, tipo questa a casa mia:
https://www.san-marco-eiscafe.de/eisgalerie/eis-becher.php



> Nella fase di conflation come gestiamo l'informazione pre-esistente in OSM
> su questi punti?  E quali di queste dettagli sono presenti nel dataset.
>


ottime domande



> Ho guardato shop=pastry nel wiki e vedo (con orrore) il suggerimento di
> utilizzare due nodi nel caso che uno stabilimento è shop=pastry e
> shop=bakery. C'è anche il suggerimento di mappare solo l'attività
> prevalente.
>


"solo" mi sembra mai una buona idea, sempre meglio aggiungere una proprietà
aggiuntiva. Nel dubbio ci metto anche il tag "restaurant:type:it" (che non
ha il nome migliore, perché viene usato in maniera generica per tutti i
tipi di gastronomia, non solo per i ristoranti):
https://taginfo.openstreetmap.org/keys/restaurant%3Atype%3Ait#values Se
vedi "rosticceria;tavola_calda;macelleria" oppure
"caffetteria;bar;gelateria" puoi farti una buona idea di cosa si tratta, ma
ovviamente solo se capisci l'italiano, quindi questi tags li vedo come
aggiunta, non da soli.



>
> Penso che prima di fare un import di rivedere il mapping e aggiornare le
> varie pagine wiki.
>


ottima proposta



> In più ho paura che anche i dati ufficiali (che volgiamo importare)
> soffrono della stessa problematica.
>


+1. In più potrebbero essere superati, come spesso è successo. Avete
controllato qualche campione nelle vostre zone?


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

[OSM-talk] EuroVelo routes are out of date

[Richard Fairhurst]

EuroVelo routes are not in a great state in OSM. Many of them appear to have 
been armchaired years ago when routes were "in development", and not updated 
since to reflect the correct route.

A handful of examples:

[France]
https://cycling.waymarkedtrails.org/#?map=12!49.2876!2.655
EV3 should follow the new cycleway along the Oise, not the busy D932a

[Czech Republic]
https://cycling.waymarkedtrails.org/#?map=11!49.9195!14.4621
EV7 is completely wrong in OSM from the south of Prague to Nahoruby, including 
unrideable tracks and a suggestion that cyclists use a “ferry” that in reality 
is a tourist boat that only operates at weekends

[Spain]
https://cycling.waymarkedtrails.org/#?map=13!41.9486!3.1467
EV8 now follows the Pirinexus alignment

…and there are lots more.

I realise people are preoccupied with tagwanking over relation tagging [1] and 
sorting [2] and editor snobbery [3], but there’s not a lot of point fretting 
over how pretty the tagging is on the route relation if the route is actually 
wrong in the first place.

Could I encourage people to check the EuroVelo routes in their home countries 
and update them where necessary?

Richard

[1] https://lists.openstreetmap.org/pipermail/tagging/2019-August/047790.html
[2] https://lists.openstreetmap.org/pipermail/tagging/2019-August/047258.html
[3] https://lists.openstreetmap.org/pipermail/tagging/2019-January/042154.html
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Import UK postcode data?

[Mark Goodge]

On 03/10/2019 01:40, nd...@redhazel.co.uk wrote:


- Code-Point Open is a legal and open source of postcode data. In fact 
it is the _only_ legal source of such data in bulk. All other sources 
are either derived from CPO or are based on local knowledge.


That's not true. The ONS Postcode Database (ONSPD) products are also 
OGL, at least as far as mainland GB postcodes are concerned (NI 
postcodes are somewhat different). And ONSPD is more useful than 
Code-Point Open, partly because it's more amenable to an automated 
update (you can script a regular download of the latest file, unlike OS 
products which need to be manually ordered each time), and partly 
because it includes more meta-data that can also be valuable (for 
example, it includes lookups to GSS codes for a wide range of 
administrative authorities).


- The key (and deliberate) limitation Code-Point Open is that it doesn't 
distinguish between residential postcodes and postcodes assigned to 
"large users". This is not ideal but still useful - we know the postcode 
exists at a given location, we just can't be sure if it is the only 
postcode there.


ONSPD solves this problem, because it includes the "large user" flag.

(Slight tangent here: residential postcodes can be "large user" too; for 
example a university hall of residence with a single address point. 
Postcodes themselves don't distinguish between residential and 
commercial use, and that information isn't reliably held anywhere, even 
in the full PAF, as that information is generally irrelevant to Royal 
Mail's purposes. But it is true that most large user postcodes are 
commercial.)


- Quality of building in OSM database. Large buildings, especially in 
town centres, are often not partitioned correctly. Different parts may 
have different street names and postcodes. Code-Point Open may in fact 
be helpful in finding and correcting such issues.


- Some postcodes are for PO boxes (usually collocated with post offices) 
are are best left out.


You can generally identify Post Office based PO Box postcodes simply by 
looking for postcodes that share identical coordinates. But, of course, 
to do that you need to have all of them; you can't do it reliably on a 
postcode-by-postcode basis.


My recommendation: import missing postcodes "as is" (as points) with 
extra tags denoting the import, import date and an accuracy metric from 
CPO. Keep it searchable and easy to remove or update, if necessary. 
Code-Point Open is updated quarterly and sometimes centroids move to 
another building. Filter out PO boxes and postcodes which are already in 
OSM (I usually check if there is an OSM object with a matching 
addr:postcode within a 10m radius of the code point). Do not attempt to 
merge them with buildings as it is not guaranteed to work in all cases. 
This is best done manually and in some cases it may require a survey.


I agree with all of that, with the exception that I'd suggest using 
ONSPD as the source (for the reasons given above). An advantage of using 
ONSPD is that the presence of the large user flag means that for 
postcodes identified as being large user (if not also PO Box postcodes), 
they do accurately and correctly identify a specific building. So they 
can be merged with the building data where possible.


Mark

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

Re: [Talk-it] [import] gelatieri e pasticcieri FVG

[Volker Schmidt]

Vorrei sollevare una domanda dal punto di vista utente finale:

Una tipica pasticceria qua (Nordest) offre questi servizi:
caffè (amenity=cafe)
bevande non alcoliche (acqua, cola, spremute, ...)
alcolici (birra, vino, liquori, ...)
ciocolatini (tipicamente asporto)
brioches (consumo sul posto)
pastine  (consumo sul posto e asporto)
semifreddi (tipicamente asporto)
caramelle

Non tutti hanno la produzione allo stesso posto del locale
Pochi vendono anche pane
Pochi vendono anche gelato (consumo sul posto)
Poi una distinzione importante per l'utente: alcuni hanno tavoli per il
consumo, altri no (solo vendita).
E probabilmente tanti altri varianti e combinazioni

Nella fase di conflation come gestiamo l'informazione pre-esistente in OSM
su questi punti?  E quali di queste dettagli sono presenti nel dataset.

Ho guardato shop=pastry nel wiki e vedo (con orrore) il suggerimento di
utilizzare due nodi nel caso che uno stabilimento è shop=pastry e
shop=bakery. C'è anche il suggerimento di mappare solo l'attività
prevalente.

Penso che prima di fare un import di rivedere il mapping e aggiornare le
varie pagine wiki.
In più ho paura che anche i dati ufficiali (che volgiamo importare)
soffrono della stessa problematica.






On Thu, 3 Oct 2019 at 00:49, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 3. Oct 2019, at 00:02, Alessandro P. via Talk-it <
> talk-it@openstreetmap.org> wrote:
>
> Scusate,
> giusto un paio di note:
> - per le pasticcerie non si usa shop=confectionery
> https://wiki.openstreetmap.org/wiki/IT:Tag:shop%3Dconfectionery ?
>
>
>
> io uso shop=pastry
> https://wiki.openstreetmap.org/wiki/IT:Tag:shop%3Dpastry
>
> è proprio un tag specifico per le pasticcerie, confectionery è per
> caramelle e altro dolciume...
>
> Ciao Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-bo] Invitation to the first Trufithon („TrufiHackathon”)

[Christoph Hanser]

*Invitation to the first Trufithon („Trufi Hackathon”) *


Let’s work one day together on the trufi app! [image: ]

Do you want to join us?!



· *When?* Saturday 15/10/2019

· *Where?* Hamburg, Cochabamba, Accra, Nicaragua, La Paz, Manila,
Kathmandu, Antananarivo…everywhere!

· *What?* Everything about trufi app, data tools, routes, designs, new
cities…



Here are some ideas about what we could do:

· For MAPPERS

· Upload missing routes from books, Guia Cochala to OpenStreetMap

· For COLLECTORS

· Collect missing routes in cities on the streets (Luz, maybe you have a
list of most-missed routes in Cochabamba?)

· For DEVELOPERS

· Create pilots for many cities that have GTFS 
 or good OpenStreetMap coverage


· Create cool features

for
the app

· Adapt apps to local markets, such as “People” page on Trotro App

· For BUSINESS

· Setup a super marketing strategy

· Write down what we did with Sven

· For NETWORKERS

· Write other NGOs in the area

· Write posts about Trufi for WRI, DATUM, DT4Africa, …

· For DATA SCIENTISTS

· Analyse our search data

· For DESIGNERS

· Create CI, Logos, Splashscreen for new cities

· …



Just do something practical, hands-on for our app, be it Trufi, Trotro,
RutaNica, Trufi El Alto/La Paz, Matatu App, Daladala App; in Asia, Africa,
South America or Europe!



Since we live in different timezones, we should setup a hangout that we
could always join and maybe visit at specific times (like 9:00, 11:00,
13:00, 15:00, 17:00 CEST) to talk about what we have.

Please write down your name, location, topic and details here so that we
know that you participate:
https://drive.google.com/file/d/1aeH30d1O8c1NkaINkHDejzzUWCj80tK_/view?usp=sharing



See you!

Trufi Team



*Trufi Association e.V.*

Rodenbeker Str. 18c, 22395 Hamburg, Germany

Mobile: +491634791397

https://www.trufi-association.org/

https://www.linkedin.com/company/trufi-association

https://www.facebook.com/TrufiAssoc/

https://twitter.com/TrufiAssoc



Why is Trufi Open Source?

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

Re: [Talk-bo] Trufi App para Sucre - ¿Quieres ser parte?

[Christoph Hanser]

Holas!

Nos hemos vuelto open source! :)
https://www.trufi.app/por-que-la-trufi-app-se-vuelve-de-codigo-abierto/

La Trufi App existe ahorita en Github.
https://github.com/trufi-association

Es una APP, escrito con Flutter.
Empezamos en Cochabamba y estamos ahora tambien en Ghana, Nicaragua,
hablamos con La Paz y ciudades en Africa y Asia. Es muy divertido y
aprendemos mucho. :)

Quieren hacerla prueba?
Quieren volverse parte del equipo y trabajar con nosotros?

Muchos saludos,
Christoph


El mar., 7 de may. de 2019 a la(s) 23:24, Christoph Hanser (
christoph.han...@gmail.com) escribió:

> Hola companer@s:
>
> Soy Christoph de la Trufi App (www.trufi.app).
>
> Nosotros hemos desarrollado una app para el transporte publico en
> Cochabamba, basado en OpenStreetMaps.
>
> Ahora conocemos a gente que quiere empezar la trufi app en Sucre y que
> estan organizan las rutas de los micros, minibuses y trufis.
>
> Vives en Sucre o tienes conocimiento del transporte aqui?
> Tienes ganas de subir rutas?
> O tienes otra idea de trabajar con nosotros en este proyecto?
> Me contacta no mas por email o WhatsApp (+491634791397).
>
> Muchos saludos,
> Christoph
>
>
> [image: image.png]*Trufi Association e.V.*
>
> Rodenbeker Str. 18B, 22395 Germany-Hamburg
> https://www.trufi.app/
> https://www.facebook.com/trufiapp/
> Mobile: +491634791397
>
>
___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [OSM-talk-fr] adresses sur tronc d'arbres

[Francois Gouget]

On Wed, 2 Oct 2019, Baptiste Lemoine - Cipher Bliss via Talk-fr wrote:
[...]
> https://www.mapillary.com/map/im/YC4fb2LeIVSO5ufjuw66bA (désolé pour 
> la qualité, y'a des affichages agraphés sur le plan, c'est malin) et 
> voici a quoi ressemblent les marquages sur les arbres. on dirait 
> clairement des adresses, sauf qu'il n'y a aucune maison dans cette 
> foret, pas de boite postale non plus. donc pour le moment j'ai mis des 
> POI marquant une adresse avec juste un numéro, mais pas de nom de rue.

C'est juste le numéro des stations du parcours sportif pour le faire 
dans l'ordre (on voit que le parcours fait un huit).

Donc mettre un point fitness_station=xxx pour chaque station, et les 
joindre dans une relation type=route + route=fitness_trail.

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dfitness_station
https://wiki.openstreetmap.org/wiki/FR:Tag:route%3Dfitness_trail

Les numéros iraient sur les points fitness_station. Le Wiki dit :

name=* a name for the fitness station
ref=* a reference number of the fitness station

Donc peut-être name="Station N" ou alors simplement ref=N.

-- 
Francois Gouget   http://fgouget.free.fr/
  Sufficently advanced incompetence is indistinguishable from malice.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresses sur tronc d'arbres

[Cyrille37 OSM]

Le 02/10/2019 à 17:30, osm.sanspourr...@spamgourmet.com a écrit :

Mais plutôt des repères propres au parcours.

ref= me semble correct, après il te reste à relier ces points 
dans un route=fitness_trail 
.



Super, ça semble bien ça.

Cyrille37.


Jean-Yvon

Le 02/10/2019 à 15:44, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Ce sont soit des numéros de parcelles dont les arbres des coins 
desdites parcelles comportent ledit numéros, ou alors si cela se 
trouvent sur un prarcours, des points décamétrique comme ici : 
https://www.openstreetmap.org/node/2415885432


Cordialement



___
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: [OSM-talk-fr] Moulinette pour convertir codes Insee en GPS > GPX ?

[Christian Quest]

On peut déjà, mais l'API est conçue pour une recherche full-text et là on a
un code INSEE de départ (qui n'est pas indexé), c'est donc le libellé
(approximatif car pas unique et inutile vu qu'on a le code INSEE non
équivoque) qui est utilisé pour la recherche.

De plus, pour moi, utiliser une API* pour résoudre ce type de problème est
quand même une aberration... il s'agit de faire un simple JOIN entre 2
fichiers, trucs que je ferai localement en ligne de commande avec csvjoin
de csvkit.

Il faut juste trouver le CSV qui contient la liste des communes avec leur
lat/lon (voire l'extraire éventuellement d'OSM**).

* Les API c'est bien, en abuser ça craint:
https://medium.com/@cq94/les-api-cest-bien-en-abuser-ca-craint-b5d1c92b32f2
** exemple: https://gist.github.com/cquest/476c7b1a3a88c0e3592690257f7e8647
via https://overpass-turbo.eu/s/MOT

Le jeu. 3 oct. 2019 à 06:46, Jérôme Seigneuret 
a écrit :

> Bonjour,
>
> @christian sur l'api adresse on peut aussi imaginer de définir le niveau
> exact où une limite à prévoir dans les types d'objets recherchés,
> output=voie, lieudit,ville,commune
>
> Jérôme
>
>
>
>
>
>
> Le mer. 2 oct. 2019 à 22:56, Christian Quest  a
> écrit :
>
>> api-adresse.data.gouv.fr est fait pour géocoder des adresses, pas des
>> noms de ville avec leur code INSEE, ça c'est le boulot de geo.api.gouv.fr
>>
>> Du coup, oui, 3190 moulins, ça peut être plein de choses...
>>
>>
>> Le mer. 2 oct. 2019 à 19:17, Shohreh  a écrit :
>>
>>> Samy Mezani wrote
>>> > L'API est faite pour automatiser tout ça :
>>> >
>>> > https://geo.api.gouv.fr/adresse (descendre à /search/csv/)
>>>
>>> Merci beaucoup.
>>>
>>> Si d'autres cherchent à faire la même chose :
>>> 1. (nécessaire?) Convertir les données entrée en UTF8
>>> 2. Downloader curl.exe dans le même répertoire
>>> 3. curl --insecure -o output.csv -X POST -F data=@input.csv -F
>>> citycode=NOMCOLONNECODEINSEE
>>> https://api-adresse.data.gouv.fr/search/csv/
>>>
>>> Bizarrement, il y a des villes que le serveur n'a pas réussi à géocoder
>>> (lat,lon vides):
>>>
>>> 3190Moulins
>>> 44090   La Marne
>>> 77083   Champs-sur-Marne
>>> 88212   Grand
>>> 92072   Sèvres
>>> 93039   L'Île-Saint-Denis
>>> 93066   Saint-Denis
>>>
>>>
>>>
>>> --
>>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>> ___
>> 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
>


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