[Talk-transit] bus=yes opinion

[Agustin Rissoli]

What are your opinion of adding bus=yes along with
public_transport=platform + highway=bus_stop?
I can't find info on the wiki that supports this practice, I know it was
introduced by iD, but I don't see where this has been discussed.
My question arises because there is only one user who is adding bus=yes
(and train=yes on railway platforms, etc.), to all stops in Argentina,
probably correcting the errors that iD marks.


Saludos, Agustín.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-GB] Paths on Wimbledon Common

[Adam Snape]

It seems a bit odd for Osmose to be flagging highway=footway, foot=yes as
an error just because foot access is implied by default. Whilst there might
be the tiniest bit of redundancy I can't see any particular reason to
remove it and, indeed, there might be an argument that an explicit tag is
always preferable to an implied value.

OT, but I've personally always viewed foot=permissive as a caveat for the
end user that a way might be closed. I only add it where a route is
explicitly stated to be permissive on the ground, is actually known or
likely to be shut from time to time, or is clearly an informal path. Many
paths through parks and housing estates etc. are clearly intended for
permanent public use and about as likely to be closed as the nearby
highways.

Kind regards,

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

Re: [OSM-ja] 7/19 京都！街歩き！マッピングパーティ：第19回 丹後 金比羅神社

[yasunari yamashita]

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

京都！街歩き！マッピングパーティ　再開の19回は、来週末の 7/19 に
日本唯一の狛猫がある丹後のこんぴらさん金刀比羅神社 と花街の残り香漂う琴平新地でニャッピングパーティ！
https://openstreetmap-kyoto.connpass.com/event/179584/

皆様の参加をお待ちしています！

2020年6月20日(土) 9:55 yasunari yamashita :
>
> 京都！街歩き！マッピングパーティ世話役の山下です。
> 皆さんこんにちわ。
>
> 新型コロナウィルスの影響でお休みしていた京都！街歩き！マッピングパーティ
> 様子を見ながら再開します！
>
> 再開の19回は、日本唯一の狛猫がある丹後のこんぴらさん金刀比羅神社 と花街の残り香漂う琴平新地でニャッピングパーティ！
> https://openstreetmap-kyoto.connpass.com/event/179584/
>
> ゆるーり街歩きしてサーベイ（現地調査）
> 金刀比羅会館で OpenStreetMap にマッピング（地図編集）、
> マッピングの後は美味しい京丹後の食材で懇親会！！
>
> 皆様の参加をお待ちしています！
> --
> 山下康成＠京都府向日市



-- 
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-GB] The curious case of USRN 20602512

[Lester Caine]

On 10/07/2020 22:27, Nick wrote:

Hi Lester

I think there needs to be some thought as to the "proper channel to feed 
corrections to the 'data officer' responsible". It took me months to get 
a 'data officer' to correct the location of a single UPRN, so my thought 
is that this needs to be a 'public' (open) channel that shows a) the 
number of issues identified (the rationale for making data open) and b) 
how long it takes for these to be investigated and resolved (if 
appropriate).


TOTALLY AGREE ... local authorities MAY be required by law to provide 
the data, but they get no funding, and no support to manage that data 
yet third parties have been making money from it! SO the next step is to 
document all the mistakes. There should be no assumption that the 
current data set IS correct, which is why it should be used as a 
parallel layer and not simply imported over what may well be more 
accurate data.



On 10/07/2020 14:21, Lester Caine wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can 
be difficult to spot errors, because the people who are most likely 
to spot errors - members of the general public with local knowledge - 
tend not to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer 
at the council covering the area. Probably originally tacked on to 
another job description and someone who probably had no training is 
this 'new' function? I was receiving NLPG updates for many years and 
the vast majority of 'updates' were corrections to data rather than 
additions. The problem has always been not allowing public access to 
what has always been public data and now we do have access there needs 
to be a proper channel to feed corrections to the 'data officer' 
responsible for the relevant slice of raw data. I don't think THAT has 
changed since the requirements for councils to provided the raw NPLG 
data passed into law? I'm fairly sure the street data is part of the 
same legal framework ...




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



--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-ca] NRCan lakes

[Hannes Röst]

Dear Pierre

 


Thanks for your reply, that makes a lot of sense. I wonder whether it may make sense to have an automated bot/script or whether this really has to be done by hand? It seems like a lot of work and its quite repetitive and the potential for error is low (merging ways that are identical).

 

Best

 

Hannes

 

 

Gesendet: Mittwoch, 08. Juli 2020 um 19:09 Uhr
Von: "Pierre Béland" 
An: "Talk-CA OpenStreetMap" 
Cc: "Hannes Röst" , "Daniel @jfd553" 
Betreff: Re: Aw: Re: [Talk-ca] NRCan lakes






Hannes,

 

Ton exemple de doublons, on le retrouve beaucoup.  Et effectivement, le validateur JOSM permet de repérer ces doublons.  Et comme Daniel l'a clairement expliqué, il faut bien connaitre les données et effectuer les correction nécessaires.

 

Voici un script Overpass pour identifier les doublons  de polygones [natural=water] vs [roles inner - natural=wood]. Cette requête Overpass peut être lancée à partir de JOSM. 

http://overpass-turbo.eu/s/VW1

 

Il faut éviter de sélectionner une zone trop grande. Le script va extraire la relation natural=wood pour la zone et les chemins en doublon./ relations où doublons avec les éléments de cette relation natural=water. 

 

Le panneau Validation permet ensuite de repérer les doublons. Pour chacun il faut ensuite corriger tout en assurant l'intégrité de la relation natural=wood.
 
Pierre 



 

 




Le mercredi 8 juillet 2020 17 h 23 min 04 s UTC−4, Hannes Röst  a écrit :

 

 






Dear Daniel

 

Thanks for your answers, I have tried to piece together this (apparently 10 year old) history of the import from the mailing list threads and the wiki and it has been somewhat difficult, especially as discussions seem to have been at multiple places. So, so many discussion about forests!...Overall there seem to be some questions about the quality and desirability of parts of the import of CanVec with the (Canadian) consus being that it is desireable to do the imports.

 

The wiki still indicates to use the canvec.osm product even though the timestamps on the files are from 2013 [1] and it is not clear whether there is a newer / updated version of the data. When I compare the OSM files of tiles from the FTP site to the Toporama product doing some spot-checks I find them to be identical for hydrological data (wetlands, rivers etc) and almost identical for forests (with Toporama having some additional "inner" ways where no forest is, but not always more accurate). If my understanding is correct that the WMS endpoints of CanVec and Toporama are up-to-date, then this allows us to compare changes in the products since 2013 when the OSM FTP dump was made. On the other hand in the release notes from 2019 [2] they point to an FTP site but that one does not contain OSM files and the release notes seem to indicate 2016-01-14 as "original release" of the current CanVec data [3]. So it seems our version from 2013 is a bit behind but probably the best we have unless somebody is willing to create another export. However, it may make sense to load the *current* Toporama WSM layer into JOSM during an import and check for any updates since the 2013 dump. On the other hand, the data is not very up to date in cities, I found a large industrial complex in the Toporama map in downtown Toronto where "Marian Engel Park" is since at least 12 years [4], so we have to keep that in mind. 

 

The wiki also suggest to use a Google Sheet to track imports, but it does not seem to be used a lot - I assume from the wikipage that you have written most of it and initiated the import, correct?

 

Best regards

 

Hannes

 

1. https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets


2. https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/22543

3. https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf

4. https://www.openstreetmap.org/way/15804193

 


Gesendet: Mittwoch, 08. Juli 2020 um 13:09 Uhr
Von: "Daniel @jfd553" 
An: "pierz...@yahoo.fr" , "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
Betreff: Re: [Talk-ca] NRCan lakes



OMG, a lot of pertinent questions!

You are summarizing questions than were discussed on this list over the last decade. Discussions about canvec/osm data modeling, internal canvec data sources, import problems, edits problems, and artifacts from osm validation tools' history!

Because of that, you cannot assume any coast-to-coast consistency with the problems you have identified, although you can find them almost everywhere.

Here are some clues. Canvec model did not change much over years but the sources used to build the product changed (from federal to provincial/municipal). As far as I know,  canvec.osm product is not maintained anymore, even if its last version is still available. When you find inconsistencies, look at data history. It may help to identify if a problem comes from an initial import, from an adjustment 

Re: [Talk-GB] The curious case of USRN 20602512

[Nick]

Hi Lester

I think there needs to be some thought as to the "proper channel to feed 
corrections to the 'data officer' responsible". It took me months to get 
a 'data officer' to correct the location of a single UPRN, so my thought 
is that this needs to be a 'public' (open) channel that shows a) the 
number of issues identified (the rationale for making data open) and b) 
how long it takes for these to be investigated and resolved (if 
appropriate).


On 10/07/2020 14:21, Lester Caine wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can 
be difficult to spot errors, because the people who are most likely 
to spot errors - members of the general public with local knowledge - 
tend not to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer 
at the council covering the area. Probably originally tacked on to 
another job description and someone who probably had no training is 
this 'new' function? I was receiving NLPG updates for many years and 
the vast majority of 'updates' were corrections to data rather than 
additions. The problem has always been not allowing public access to 
what has always been public data and now we do have access there needs 
to be a proper channel to feed corrections to the 'data officer' 
responsible for the relevant slice of raw data. I don't think THAT has 
changed since the requirements for councils to provided the raw NPLG 
data passed into law? I'm fairly sure the street data is part of the 
same legal framework ...




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

Re: [Talk-GB] Paths on Wimbledon Common

[Stephen Colebourne]

Hi, I'm the changeset commenter,
I added the foot=yes on the common based on it being a registered common
with definite legal access. I also add foot=yes to signed public footpaths.
I would only add foot=designated where there is a blue person sign or
similar (not a green/wooden public footpath sign) and where doing so adds
some value over just using the default. And I'm not sure I've ever actually
used it.

In general I'm wary of the legal aspect of the tag, as in most cases a
mapper has no idea of the legal status. My approach (SW London urban areas)
is based on a less legalistic interpretation:
* foot=private if it looks private
* "customers" if it is obviously for customers
* "destination" if it is obviously just for those going somewhere in
particular, such as a path to a school or church
* "permissive" if it is likely to be private land but it is known or almost
certainly used by others, paths on housing estates being an example
* "yes" if I'm confident of the legal status, such as common land and
public footpaths
* nothing otherwise, and this includes sidewalks

Stephen


On Fri, 10 Jul 2020, 17:02 Adam Snape,  wrote:

> Hi,
>
> It's worth pointing out that if Wimbledon Common is (as I assume)
> registered as common land then there would normally be a legal right of
> access on foot under the Countryside and Rights of Way Act 2000, so
> foot=yes would be correct.
>
> Kind regards,
>
> Adam
>
>
> ___
> 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: [OSM-talk-fr] Test mission Pic4Review "Passage piéton en fauteuil roulant"

[Gad Jo]

Je viens de corriger la description pour ajouter "parfait" à "aucune 
restriction". L'idée est de conserver un texte court pour les petit écran.

Yes pas de source dans le changeset mais le détail de la source est présent sur 
chacune des modifications. L'image mapillary associé est placé sur le nœud.

Ce week-end je fait une version en anglais et je propose cette mission comme 
modèle à la place de celle déjà existante.

Je travail sur deux missions en lien avec les panneaux publicitaire mais cette 
fois ci ça demande des modifications dans le code de pic4review (conflit de tag 
entre les deux missions). Quand j'aurai monté une instance locale il est 
probable que je remonte quelques questions à ce sujet dans un sujet dédié.
Pour les curieux c'est les missions (en test) 
https://pic4review.pavie.info/#/mission/1161
https://pic4review.pavie.info/#/mission/1174

Le July 10, 2020 9:21:01 AM UTC, "Éric Gillet"  a 
écrit :
>Le 09/07/2020 à 14:21, Percherie OnDaNet a écrit :
>> La mission "Passages piéton en fauteuil roulant" : 
>> https://pic4review.pavie.info/#/mission/1103
>>
>> Avant de la proposer comme modèle sur Pic4Review, pouvez-vous
>vérifier 
>> si je n'ai pas fait de coquille dans les tags utilisé ? Vous pouvez 
>> les consulter quand vous dupliquez la mission pour votre zone. Au 
>> besoin je peut les énumérer ici mais si je peut éviter de polluer la 
>> liste.
>
>Petit détail, mais je pense qu'il faudrait homogénéiser les termes
>entre 
>les boutons de la revue et sa présentation (exemple "Parfait"="Aucune 
>restriction").
>
>Autre soucis mais sûrement plus général à Pic4Review, il n'indique pas 
>la source (image Mapillary par ex.) dans les changesets.
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-lt] Vilniaus sektorinis eismas

[Tomas Straupis]

Sveiki

  Atsinaujino OSRM maršrutizavimo duombazė, žvilgterkit į Vilniaus
Senamiesčio eismą, kas žinote niuansus:
  http://map.project-osrm.org

  Pagrindines taisykles lyg ir sudėliojom, bet yra visokių mažyčių
detalių, kurios visą mintį* sugadina, tarkim ar nėra uždrausta
Vokiečių gatvėje va taip apsisukti, norint patekti į kitą sektorių?
  
http://map.project-osrm.org/?z=18=54.678662%2C25.285517=54.678421%2C25.286579=54.678006%2C25.286332=en=0=0

  Ačiū

* pagrindinė mintis, aišku, yra nelįsti į Senamiestį ne gyventojams su
automotorais.

-- 
Tomas

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

Re: [Talk-GB] Paths on Wimbledon Common

[Mike Baggaley]

>I have been doing some tidying based on Osmose, including the warning for 
>highway=footway foot=yes, which is often left over >from a preset in Potlatch 
>1.
>
>https://www.openstreetmap.org/changeset/87672607
>
>I got a changeset comment querying the edit.

Hi Andrew,

My understanding is that highway=footway with no access tags has an implied 
foot=yes. This, however is entirely different from highway=footway + foot=yes 
which explicitly states that access is allowed. Without the explicit tag, 
whilst routing will be the same, it could just be that the mapper adding the 
path did not know whether access was allowed. In my view, if there is a rule 
check, it should be checking that there IS either a foot= tag or an access=tag 
and warning if there isn't. For me however, the biggest problem is ways tagged 
with highway=footway, access=no and foot=yes - this really should be warned 
about, as without reading the change history and notes it is not possible to 
determine whether the access=no was intended to indicate that other access than 
foot is disallowed (which is superfluous) or was added to say the path has been 
closed, forgetting that foot=yes will override it. The feedback comment 
mentioned 'designated' - I think foot=designated should ideally only be used in 
conjunction with the designation= tag, as otherwise you don't know what 
designation designates the access. There are also lots of ways tagged with 
values of 'designated' for transport modes where the mapper had an incorrect 
understanding of what it meant, so without the accompanying designation tag, 
these values should be taken with a pinch of salt.

Regards,
Mike


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

Re: [OSM-talk-fr] Suppression *covid19=*

[Philippe Verdy]

Le ven. 10 juil. 2020 à 14:34, deuzeffe  a écrit :

> Le 10/07/2020 à 13:04, Philippe Verdy a écrit :
> L'auteur, enfin, l'autrice initiale, c'est moi (qui voulais supprimer et
> non pas "virer"). Étonnant, n'est-ce pas ? Et il s'agit bien de données
> d'usage dans un périmètre local parfaitement connu de moi-même. C'est
> curieux, n'est-ce pas ?
>

Tu joues sur les mots, "virer" et "supprimer" sont synonymes et l'emploi de
l'un pour l'autre ne montrait aucune mauvaise intention, c'est un usage
courant.
Et même pour un usage local, virer les tags qui sont encore utiles (et pas
contribués seulement par toi ou pour toi) est une mauvaise idée pour
l'instant. C'est bien ce que j'ai commenté et c'était le sujet de cette
discussion.
Donc en plein accord avec la "netiquette" que tu croies vouloir interpréter
selon tes préférences alors que cela ne concerne en rien ce que j'ai écrit
ni la façon dont je l'ai écrit
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression *covid19=*

[Philippe Verdy]

Le ven. 10 juil. 2020 à 14:34, deuzeffe  a écrit :

> Le 10/07/2020 à 13:04, Philippe Verdy a écrit :
>
> Bonjour aussi.
>
> > /SNIP ta réponse... je n'ai pas été "impoli" envers qui que ce
> > soit...
>
> Si, envers tous les lecteurs de la ML. Tu as eu parlé le la nétiquette :
> tu faisais référence à quoi ?
>

Tu ne références rien du tout concernant la netiquette dont je n'abuse
aucun terme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le retour du rendu "QA" et des "layers"

[Philippe Verdy]

Oui mais la base a du retard à rattraper... les modifs ne sont pas visibles
avant au moins 24 heures (apparemment la base est chargée à minuit)

Le sam. 4 juil. 2020 à 17:37, Christian Quest  a
écrit :

> Il s'agit du rendu qui compare les données OSM avec le carroyage de la
> population de l'INSEE.
>
> Le principe:
>
> - l'INSEE publie la population répartie sur tout le territoire par
> carreaux de 200m de côté.
>
> - on doit donc trouver à proximité d'un carreau des bâtiments et des
> routes...
>
> Plus d'info ici:
>
>
> https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Couche_.22Zones_.C3.A0_mapper.22
>
>
> Jocelyn a aussi remis en place les couches de "layers.openstreetmap.fr",
> avec les limites admin, les voies sans nom, etc...
>
>
> Tout est visible sur
>
> http://layers.openstreetmap.fr/?zoom=8=47.7062=2.77204=000B00FFTFF
>
> --
> 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

Re: [Talk-GB] Paths on Wimbledon Common

[Adam Snape]

Hi,

It's worth pointing out that if Wimbledon Common is (as I assume)
registered as common land then there would normally be a legal right of
access on foot under the Countryside and Rights of Way Act 2000, so
foot=yes would be correct.

Kind regards,

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

Re: [Talk-GB] The curious case of USRN 20602512

[Mark Goodge]

On 10/07/2020 16:00, Kai Michael Poppe - OSM wrote:

After not having any luck in finding out of copyright maps that helped I 
wondered, if a FOI request to Ealing Council, naming the exact location 
and asking for the name would be fruitful. Did anyone ever try something 
like this? Would this then be seen as a source compliant to the ODbL?


I suspect that an FOI request would return the name that's in the NSG. 
That is, Fairfield Road. It's unlikely that the FOI officer will do 
anything other than look up the street on the computer, and take the 
answer they are given.


I'm not sure whether that's acceptable for ODbL or not. There's a lot of 
data that can be released under FOI that can't be reused because it 
contains proprietary information. This may come under that category.


Mark

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

Re: [Talk-GB] The curious case of USRN 20602512

[Mark Goodge]

On 10/07/2020 14:21, Lester Caine wrote:

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can 
be difficult to spot errors, because the people who are most likely to 
spot errors - members of the general public with local knowledge - 
tend not to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer at 
the council covering the area. Probably originally tacked on to another 
job description and someone who probably had no training is this 'new' 
function? I was receiving NLPG updates for many years and the vast 
majority of 'updates' were corrections to data rather than additions. 
The problem has always been not allowing public access to what has 
always been public data and now we do have access there needs to be a 
proper channel to feed corrections to the 'data officer' responsible for 
the relevant slice of raw data. I don't think THAT has changed since the 
requirements for councils to provided the raw NPLG data passed into law? 
I'm fairly sure the street data is part of the same legal framework ...


There is a process for changing the name of a street, yes. It's a bit 
cumbersome and bureaucratic, but it's doable.


The problem with correcting an error on the NSG is that, unless it is a 
clear and obvious error (such as a typo), and there is current 
documentation which shows the correct form of the name, it has to be 
treated as a name change rather than an error correction.


So, for example, if the NSG says "Coronaton Street" for a street on a 
new development, but the minutes of the relevant meeting where new 
street names were discussed clearly shows that it was resolved to call 
it "Coronation Street", then that is a clear and obvious error which can 
be corrected without the need for any further hurdles to jump.


But, on the other hand, if the NSG has "Victoria Square" for a street 
that has been there since Victorian times and was entered into the NSG 
as "Victoria Square" in the 1990s when the NSG was first created, then 
even if absolutely everybody who lives there knows that it really should 
be "Albert Square", and there are records dating back to the 19th 
century which show it as "Albert Square", and even if it's always been 
"Albert Square" on the OS maps, then it still needs to go through a full 
change of name process to get the NSG updated to say "Albert Square". 
And that can't be done just by asking for it, it needs the support of 
the local councillors at district or borough level as well as, if 
appropriate, the support of the local parish council. And getting that 
support can be problematic.


(This scenario is precisely what happened in the case I was involved in; 
a village lane that had been known by a particular name for centuries, 
and was still known by that name by the locals, had, somehow, ended up 
in the NSG in 1991 under a completely different name. And getting that 
changed was a whole world of pain.)


Mark

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

Re: [OSM-talk-fr] Suppression *covid19=*

[Rpnpif]

Merci de ne pas alimenter le troll ou si vous préférez la polémique stérile.

Bien à vous.

Rpnpif

Le 10/07/2020 à 14:33, deuzeffe a écrit :

Le 10/07/2020 à 13:04, Philippe Verdy a écrit :

Bonjour aussi.


/SNIP ta réponse... je n'ai pas été "impoli" envers qui que ce
soit...


Si, envers tous les lecteurs de la ML. Tu as eu parlé le la nétiquette 
: tu faisais référence à quoi ?



Et Wikipedia n'est pas une référence sur le sujet.


Et Wikipedia est une encyclopédie libre, ouverte et collaborative,
s'appuyant sur le savoir d'une communauté expérimentée. Un peu comme
OpenStreetMap, tu vois ? Oserais-tu dire qu'osm n'est pas une 
référence ? Ou son wiki pour les contributeurs ?



Ma réponse était parfaitement cadrée sur le sujet...


Non. Tu n'as donné aucune réponse pratique et technique pour bâtir la
requête overpass demandée.

Je te rappelle la question, puisque tu sembles ne pas l'avoir lue : 
"Quelle requête overpass pour supprimer les tags covid19 devenus 
inappropriés dans ma commune ?" Et ta réponse, est ?


Heureusement que deux autres contributeurs ont parfaitement répondu à 
la question posée, même avec quelques différences.



Puisque l'auteur initial souhaitait "virer" les tags qu'ils jugent
maintenant "inutiles" alors que rien n'est fini, bien au contraire,
ce sont jute les conditions locales d'usage 


L'auteur, enfin, l'autrice initiale, c'est moi (qui voulais supprimer 
et non pas "virer"). Étonnant, n'est-ce pas ? Et il s'agit bien de 
données d'usage dans un périmètre local parfaitement connu de 
moi-même. C'est curieux, n'est-ce pas ?



qui peuvent évoluer et
revenir. c'est bête de gâcher le patient travail des autres 


Manque de bol "les autres", dans ce cas précis, c'est moi aussi.

/snip le HS.


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

Re: [Talk-GB] Paths on Wimbledon Common

[Philip Barnes]

On Fri, 2020-07-10 at 11:54 +, Andrew Hain wrote:
> I have been doing some tidying based on Osmose, including the warning
> for highway=footway foot=yes, which is often left over from a preset
> in Potlatch 1.
> 
> 
> 
> 
> 
> https://www.openstreetmap.org/changeset/87672607
> 
> 
> 
> 
> 
> I got a changeset comment querying the edit.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I note you have removed foot=yes from highway=footway. My
> understanding is that the default for a footway is foot=designated,
> but designated requires an explicit sign. the paths on Wimbledon
> Common do not have an explicit sign, but are legally
>  accessible, hence foot=yes. Perhaps osmose is wrong.Any comments?
> --Andrew
> 
> 
> 
> 
Assuming that you can walk there and from other comments in this thread
you can, then what harm was the tag doing?
QA tools, like compiler warnings, do need to be used with care. 
These are just warnings, not errors, which say you may want check this.
They are not saying this must be fixed.
Phil (trigpoint)
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] The curious case of USRN 20602512

[Kai Michael Poppe - OSM]

Thank you for this absolute masterpiece of detective work, Marc! I'd never 
thought that looking through old Notes would spark such an interest :)

As reported before, my own dip into having USRN data underlying JOSM at that 
particular point showed that this stub (in USRN the part where the barrier is 
to the northeast of the way isn't shown, so I guess that's really a small part 
of highway=footway) is recorded with the USRN you named. So I also believe that 
this isn't something to find copyright infringements - because the way exists, 
Google Street view clearly shows people walking along that way.

After not having any luck in finding out of copyright maps that helped I 
wondered, if a FOI request to Ealing Council, naming the exact location and 
asking for the name would be fruitful. Did anyone ever try something like this? 
Would this then be seen as a source compliant to the ODbL?

Kai


Am 10. Juli 2020 12:27:24 MESZ schrieb Mark Goodge :
>Apologies for the long read, but this may be interesting to some folk. 
>This follows on from my earlier response to Kai Michael Poppe about 
>"Fairfield Road" in Ealing.
>
>On 04/07/2020 12:02, I wrote:
>> 
>> To find the USRN of the path, you need to use the lookup tables supplied 
>> by OS. Doing that, we find that the associated USRN is 20602512.
>> 
>> Now, there's no open data source which will directly tell you the name 
>> of a USRN (at least, not until we start putting them into OSM). The long 
>> way of doing so is to find the matching LineString in OS OpenMap Local, 
>> and see what name it has there.
>> 
>> However, it can be done directly via a non-open source. If you go to 
>> https://www.findmystreet.co.uk/map and zoom in on the location, then 
>> click the street to bring up the USRN details, it will give the name 
>> (and also confirm that the USRN from the OS lookup table is correct). Or 
>> use the search box and search for USRN 20602512.
>> 
>>  From an OSM point of view, that would normally be a dead end. Even if 
>> you can view the information on a non-open source, you can't incorporate 
>> it into OSM. However, in this case, we already have an abbreviated name 
>> from an open source. So all we are learning from the closed source is 
>> the full text of the abbreviation. Whether that makes it acceptable to 
>> include the full name into OSM is a matter of debate. I'll leave that 
>> decision up to others, but, for reference, the name of the street is 
>> Fairfield Road.
>
>I've been doing a bit more research in this, as it piqued my interest. 
>And the results are a little surprising.
>
>For a start, USRN 20602512 doesn't match Fairfield Road in OS LocalMap 
>Open. In fact, there's no Fairfield Road anywhere near there in OSLMO. 
>Matching the coordinates indicates that, as far as OS is concerned, it's 
>a part of Southdown Avenue. That's not particularly unusual, access 
>roads off named streets often don't have a name of their own, they're 
>either completely unnamed or share the name of their parent street.
>
>However, I did wonder whether this might just be a limitation on OS Open 
>Data, and whether MasterMap might actually include the name. That's not 
>reusable in OSM, of course, but it might help point to an open source 
>that does contain it.
>
>But it seems that even MasterMap doesn't have that name. You can check 
>that by looking at Ealing's online GIS website:
>
>http://maps.ealing.gov.uk/Webreports/Planning/Planning.html
>
>This is a planning application map, but it's just a window into their 
>GIS system and you can turn off the planning layers. Anyway, zoom all 
>the way in to the street in question - I can't give you a persistent 
>link, but it's just above the LA boundary in the bottom middle of the 
>map - and... it still has no name. At the highest zoom level, this is 
>MasterMap, and every named object has its name displayed. But there's no 
>name here.
>
>Google, also, knows nothing of a Fairfield Road here. Using the Maps API 
>to query the coordinates of USRN 20602512, we either get Southdown 
>Avenue, again, or Boston Gardens, which is the postal address of 
>buildings facing Boston Road. You can see that name on the road sign via 
>Google Streetview:
>
>https://goo.gl/maps/KGLbRC75mQw43PCV6
>
>So, it seems that Fairfield Gardens isn't known to either OS or Google. 
>It is shown (in abbreviated form) on streetmap.co.uk, but at that zoom 
>level, in London, that's based on the Bartholomew A-Z maps rather than OS.
>
>Given that, we can't include the name "Fairfield Road" in OSM as it's 
>only available from non-open sources. But even those non-open sources 
>don't agree on the name. That seems to me to lead to two possibilities:
>
>1. It doesn't exist at all. It's just a map trap designed to catch out 
>unwary copyright infringers. That's certainly a possibility, and A-Z 
>maps are known to use those. But that doesn't explain its presence in 
>the USRN database.
>
>2. The USRN name is wrong, but that error has 

[OSM-co] Configuracion WMS abierto bog en JOSM

[Rodrigo Castiblanco]

Buenos dias Maperos

Alguno ha podido usar un WMS de los datos abiertos de Bogota en JOSM?

de estos: https://datosabiertos.bogota.gov.co/dataset?q=UAECD

He intentado con varios y ninguno funciona.

Gracias !
Rodrigo
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-GB] Paths on Wimbledon Common

[Mateusz Konieczny via Talk-GB]

Jul 10, 2020, 14:49 by ajt1...@gmail.com:

> On 10/07/2020 12:54, Andrew Hain wrote:
>
>> I have been doing some tidying based on Osmose, including the warning for 
>> highway=footway foot=yes, which is often left over from a preset in Potlatch 
>> 1.
>>
>> https://www.openstreetmap.org/changeset/87672607
>>
> If Osmose is flagging "highway=footway;foot=yes" as a warning I'd suggest 
> that that is a problem that needs logging with Osmose.
>
It may be the best to make it a bit smarter - it is a completely valid 
suggestion in for example Poland.

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

Re: [Talk-GB] Paths on Wimbledon Common

[Robert Skedgell]

On 10/07/2020 13:35, David Woolley wrote:
> On 10/07/2020 13:11, Colin Smale wrote:
>> What does "legally accessible" mean? Are they Public Footpaths? Do we
>> tag all Public Footpaths with an explicit "foot=yes" or is
>> "designation=public_footpath" enough?
>>
> 
> I don't know the situation in Wimbledon Common, but most footpaths in
> public park are more correctly described as access=permissive.

foot=permissive might be better, as that doesn't imply anything at all
for other transport modes.

> 
> My understanding is that designated only has meaning if combined with an
> access type tag with a value of designated.
> 

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

Re: [Talk-GB] The curious case of USRN 20602512

[Lester Caine]

On 10/07/2020 11:27, Mark Goodge wrote:
This is, of course, one of the problems with proprietary data. It can be 
difficult to spot errors, because the people who are most likely to spot 
errors - members of the general public with local knowledge - tend not 
to have easy access to the data.


Spot on ...
The 'proprietary data' is however the input from the relevant officer at 
the council covering the area. Probably originally tacked on to another 
job description and someone who probably had no training is this 'new' 
function? I was receiving NLPG updates for many years and the vast 
majority of 'updates' were corrections to data rather than additions. 
The problem has always been not allowing public access to what has 
always been public data and now we do have access there needs to be a 
proper channel to feed corrections to the 'data officer' responsible for 
the relevant slice of raw data. I don't think THAT has changed since the 
requirements for councils to provided the raw NPLG data passed into law? 
I'm fairly sure the street data is part of the same legal framework ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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

Re: [Talk-GB] Paths on Wimbledon Common

[Andy Townsend]

(apologies for the double reply)

I just remembered I wrote a diary entry last year about this: 
https://www.openstreetmap.org/user/SomeoneElse/diary/391053 . That has 
some useful links in such as a pointer to the start of "designation" 
tagging, in 2009: 
https://lists.openstreetmap.org/pipermail/talk/2009-March/035412.html .


Best Regards (again),

Andy


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

[Talk-it] Landuse

[Manuel]

Cambio oggetto perché la discussione ormai è su altro.
Dunque, ci ho pensato a lungo e devo ammettere che l'approccio di Martin mi sembra 
adatto, considerato che anche per il landuse=farmland facevo già la stessa cosa, evitando 
di "coprire" strade e masse d'acqua.

Manuel
Il 30/06/2020 10:45, Martin Koppenhoefer ha scritto:



Am Mo., 29. Juni 2020 um 13:58 Uhr schrieb Manuel mailto:mannivuw...@gmail.com>>:

Sono d'accordo sul parco, ma per il resto l'uso di un landuse che comprenda tutta 
la zona residenziale del paese è molto esteso (anche in Germania - che spesso è presa 
a esempio - l'uso del landuse=residential è fatto in modo simile - es. la zona 
residenziale di Heidelberg ).




infatti, sto cercando di convincere anche i tedeschi ;-)

Ciao
Martin


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

Re: [Talk-GB] Paths on Wimbledon Common

[Andy Townsend]

On 10/07/2020 12:54, Andrew Hain wrote:
I have been doing some tidying based on Osmose, including the warning 
for highway=footway foot=yes, which is often left over from a preset 
in Potlatch 1.


https://www.openstreetmap.org/changeset/87672607

If Osmose is flagging "highway=footway;foot=yes" as a warning I'd 
suggest that that is a problem that needs logging with Osmose.


Speaking for myself, I've tagged "highway=footway" as "foot=yes" (where 
there is a legal right of way, such as a public footpath in England and 
Wales, or across access land), as "foot=permissive" where there isn't a 
legal right of way but general access is permitted (perhaps in 
parks/gardens that are occasionally closed but aren't restricted to 
"customers" and where there is no legal right of access) and as 
"foot=designated" where there's actual signage that suggests that foot 
traffic should go _this_ way rather than some other way which would 
otherwise be legal.


I'd also use "designation=public_footpath" if appropriate (and also set 
"foot=yes" on those to make it clear to everyone who might not 
understand a "designation" tag).  Prior to that tag being adopted, there 
was some use of "foot=designated" to indicate "this is a public 
footpath" but about 10 years ago or so (I think) people started using 
"designation=public_footpath" instead.


In summary - I'd agree with the changeset commenter that "foot=yes" was 
useful on those paths as it made it explicit that there was legal access 
for foot traffic despite there being no public footpath there.


Best Regards,

Andy



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

Re: [Talk-GB] Paths on Wimbledon Common

[David Woolley]

On 10/07/2020 13:11, Colin Smale wrote:
What does "legally accessible" mean? Are they Public Footpaths? Do we 
tag all Public Footpaths with an explicit "foot=yes" or is 
"designation=public_footpath" enough?




I don't know the situation in Wimbledon Common, but most footpaths in 
public park are more correctly described as access=permissive.


My understanding is that designated only has meaning if combined with an 
access type tag with a value of designated.


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

Re: [OSM-talk-fr] Suppression *covid19=*

[deuzeffe]

Le 10/07/2020 à 13:04, Philippe Verdy a écrit :

Bonjour aussi.


/SNIP ta réponse... je n'ai pas été "impoli" envers qui que ce
soit...


Si, envers tous les lecteurs de la ML. Tu as eu parlé le la nétiquette : 
tu faisais référence à quoi ?



Et Wikipedia n'est pas une référence sur le sujet.


Et Wikipedia est une encyclopédie libre, ouverte et collaborative,
s'appuyant sur le savoir d'une communauté expérimentée. Un peu comme
OpenStreetMap, tu vois ? Oserais-tu dire qu'osm n'est pas une référence 
? Ou son wiki pour les contributeurs ?



Ma réponse était parfaitement cadrée sur le sujet...


Non. Tu n'as donné aucune réponse pratique et technique pour bâtir la
requête overpass demandée.

Je te rappelle la question, puisque tu sembles ne pas l'avoir lue : 
"Quelle requête overpass pour supprimer les tags covid19 devenus 
inappropriés dans ma commune ?" Et ta réponse, est ?


Heureusement que deux autres contributeurs ont parfaitement répondu à la 
question posée, même avec quelques différences.



Puisque l'auteur initial souhaitait "virer" les tags qu'ils jugent
maintenant "inutiles" alors que rien n'est fini, bien au contraire,
ce sont jute les conditions locales d'usage 


L'auteur, enfin, l'autrice initiale, c'est moi (qui voulais supprimer et 
non pas "virer"). Étonnant, n'est-ce pas ? Et il s'agit bien de données 
d'usage dans un périmètre local parfaitement connu de moi-même. C'est 
curieux, n'est-ce pas ?



qui peuvent évoluer et
revenir. c'est bête de gâcher le patient travail des autres 


Manque de bol "les autres", dans ce cas précis, c'est moi aussi.

/snip le HS.
--
deuzeffe

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

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[Jose Luis Infante]

Hola,

gracias al enlace que ha enviado Andy y el enlace a la discusión que ha
enviado Alejandro, he comprobado que algunos de los elementos que formaban
las aguas territoriales todavía existen.

También he visto que un usuario con una única edición en su haber, borró y
modificó alguno de los elementos (
https://www.openstreetmap.org/changeset/50695157),

Parece que sería cuestión de recuperar las relaciones y las vías
borradas/modificadas, aunque dada la antigüedad de la edición es muy
probable que aparezcan conflictos.

Un saludo,

Jose Luis

El vie., 10 jul. 2020 a las 13:28, David Marín Carreño ()
escribió:

> Yo uniría esta reclamación con el tema de Gibraltar, ya que el caso es
> exactamente el mismo, y la resolución debería ser igual: aguas
> territoriales reclamadas, pero no reconocidas por una parte.
>
> Así, si la política o normas de OSM nos quita las aguas territoriales de
> Ceuta y Melilla, al menos recuperaríamos las de Gibraltar ;-D
>
> --
> David Marín Carreño 
>
>
>
> El vie., 10 jul. 2020 a las 12:13, Alejandro Moreno ()
> escribió:
>
>> El tema parece que se discutió hace unos años en
>> https://forum.openstreetmap.org/viewtopic.php?pid=606038#p606038
>>
>> El vie., 10 jul. 2020 a las 11:54, Andy Townsend ()
>> escribió:
>>
>>> On 10/07/2020 09:38, Miguel Sevilla-Callejo wrote:
>>> > Buscando por aquella vez que "metí las narices en el caso" [1]
>>> > encontré este changset [2]
>>> > Por algún lado debe estar mi interacción con la gente que maneja los
>>> > límites internacionales.
>>> >
>>> > [1] https://tinyurl.com/y9n387qk
>>> >
>>> > [2] https://www.openstreetmap.org/changeset/49804213
>>>
>>> Also see https://overpass-api.de/achavi/?changeset=49804213
>>>
>>> Best Regards,
>>>
>>> Andy
>>>
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-GB] Paths on Wimbledon Common

[Silent Spike]

The changeset comment seems backwards to me, foot=designated is more
specific than foot=yes (which would be the default for any mapped footpath).

On Fri, Jul 10, 2020 at 1:12 PM Colin Smale  wrote:

> What does "legally accessible" mean? Are they Public Footpaths? Do we tag
> all Public Footpaths with an explicit "foot=yes" or is
> "designation=public_footpath" enough?
>
>
>
> On 2020-07-10 13:54, Andrew Hain wrote:
>
> I have been doing some tidying based on Osmose, including the warning for
> highway=footway foot=yes, which is often left over from a preset in
> Potlatch 1.
>
> https://www.openstreetmap.org/changeset/87672607
>
> I got a changeset comment querying the edit.
>
>
>
>- I note you have removed foot=yes from highway=footway. My
>understanding is that the default for a footway is foot=designated, but
>designated requires an explicit sign. the paths on Wimbledon Common do not
>have an explicit sign, but are legally accessible, hence foot=yes. Perhaps
>osmose is wrong.
>- Any comments?
>- --
>- Andrew
>
>
> ___
> 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Paths on Wimbledon Common

[Colin Smale]

What does "legally accessible" mean? Are they Public Footpaths? Do we
tag all Public Footpaths with an explicit "foot=yes" or is
"designation=public_footpath" enough?

On 2020-07-10 13:54, Andrew Hain wrote:

> I have been doing some tidying based on Osmose, including the warning for 
> highway=footway foot=yes, which is often left over from a preset in Potlatch 
> 1. 
> 
> https://www.openstreetmap.org/changeset/87672607 
> 
> I got a changeset comment querying the edit.
> 
> * I note you have removed foot=yes from highway=footway. My understanding is 
> that the default for a footway is foot=designated, but designated requires an 
> explicit sign. the paths on Wimbledon Common do not have an explicit sign, 
> but are legally accessible, hence foot=yes. Perhaps osmose is wrong.
> * Any comments?
> * --
> * Andrew
> 
> ___
> 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-GB] Paths on Wimbledon Common

[Dan S]

I have always believed that highway=footway in the UK implies foot=yes (and
not foot=designated), though I actually don't know if UK tagging practice
is successfully documented. IMHO the use of "designated" is quite specific
and probably shouldn't be assumed as an invisible default.

Best
Dan


Op vr 10 jul. 2020 om 12:55 schreef Andrew Hain :

> I have been doing some tidying based on Osmose, including the warning for
> highway=footway foot=yes, which is often left over from a preset in
> Potlatch 1.
>
> https://www.openstreetmap.org/changeset/87672607
>
> I got a changeset comment querying the edit.
>
>
>
>
>
>
>- I note you have removed foot=yes from highway=footway. My
>understanding is that the default for a footway is foot=designated, but
>designated requires an explicit sign. the paths on Wimbledon Common do not
>have an explicit sign, but are legally accessible, hence foot=yes. Perhaps
>osmose is wrong.
>- Any comments?
>- --
>- Andrew
>
>
> ___
> 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

[Talk-GB] Paths on Wimbledon Common

[Andrew Hain]

I have been doing some tidying based on Osmose, including the warning for 
highway=footway foot=yes, which is often left over from a preset in Potlatch 1.

https://www.openstreetmap.org/changeset/87672607

I got a changeset comment querying the edit.






  *   I note you have removed foot=yes from highway=footway. My understanding 
is that the default for a footway is foot=designated, but designated requires 
an explicit sign. the paths on Wimbledon Common do not have an explicit sign, 
but are legally accessible, hence foot=yes. Perhaps osmose is wrong.
  *   Any comments?
  *   --
  *   Andrew

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

Re: [Talk-GB] The curious case of USRN 20602512

[Nick]

Hi Mark

Brilliant comment - "because the people who are most likely to spot 
errors - members of the general public with local knowledge - tend not 
to have easy access to the data". Now we need the evidence (errors) 
collated centrally (OSM?).


On 10/07/2020 11:27, Mark Goodge wrote:
Apologies for the long read, but this may be interesting to some folk. 
This follows on from my earlier response to Kai Michael Poppe about 
"Fairfield Road" in Ealing.


On 04/07/2020 12:02, I wrote:


To find the USRN of the path, you need to use the lookup tables 
supplied by OS. Doing that, we find that the associated USRN is 
20602512.


Now, there's no open data source which will directly tell you the 
name of a USRN (at least, not until we start putting them into OSM). 
The long way of doing so is to find the matching LineString in OS 
OpenMap Local, and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). 
Or use the search box and search for USRN 20602512.


 From an OSM point of view, that would normally be a dead end. Even 
if you can view the information on a non-open source, you can't 
incorporate it into OSM. However, in this case, we already have an 
abbreviated name from an open source. So all we are learning from the 
closed source is the full text of the abbreviation. Whether that 
makes it acceptable to include the full name into OSM is a matter of 
debate. I'll leave that decision up to others, but, for reference, 
the name of the street is Fairfield Road.


I've been doing a bit more research in this, as it piqued my interest. 
And the results are a little surprising.


For a start, USRN 20602512 doesn't match Fairfield Road in OS LocalMap 
Open. In fact, there's no Fairfield Road anywhere near there in OSLMO. 
Matching the coordinates indicates that, as far as OS is concerned, 
it's a part of Southdown Avenue. That's not particularly unusual, 
access roads off named streets often don't have a name of their own, 
they're either completely unnamed or share the name of their parent 
street.


However, I did wonder whether this might just be a limitation on OS 
Open Data, and whether MasterMap might actually include the name. 
That's not reusable in OSM, of course, but it might help point to an 
open source that does contain it.


But it seems that even MasterMap doesn't have that name. You can check 
that by looking at Ealing's online GIS website:


http://maps.ealing.gov.uk/Webreports/Planning/Planning.html

This is a planning application map, but it's just a window into their 
GIS system and you can turn off the planning layers. Anyway, zoom all 
the way in to the street in question - I can't give you a persistent 
link, but it's just above the LA boundary in the bottom middle of the 
map - and... it still has no name. At the highest zoom level, this is 
MasterMap, and every named object has its name displayed. But there's 
no name here.


Google, also, knows nothing of a Fairfield Road here. Using the Maps 
API to query the coordinates of USRN 20602512, we either get Southdown 
Avenue, again, or Boston Gardens, which is the postal address of 
buildings facing Boston Road. You can see that name on the road sign 
via Google Streetview:


https://goo.gl/maps/KGLbRC75mQw43PCV6

So, it seems that Fairfield Gardens isn't known to either OS or 
Google. It is shown (in abbreviated form) on streetmap.co.uk, but at 
that zoom level, in London, that's based on the Bartholomew A-Z maps 
rather than OS.


Given that, we can't include the name "Fairfield Road" in OSM as it's 
only available from non-open sources. But even those non-open sources 
don't agree on the name. That seems to me to lead to two possibilities:


1. It doesn't exist at all. It's just a map trap designed to catch out 
unwary copyright infringers. That's certainly a possibility, and A-Z 
maps are known to use those. But that doesn't explain its presence in 
the USRN database.


2. The USRN name is wrong, but that error has propagated to the A-Z maps.

Personally, I think that the second option is the most likely. And, if 
so, it wouldn't be the only error in USRN. One of the things I had to 
deal with a few years ago, in my capacity as a district councillor, 
was a country lane in my ward that had the wrong name assigned to it 
in USRN. After a bit of investigation, we concluded that it had simply 
been a transcription error back in the late 90s when the local 
gazetteer was first digitised, but it had gone unnoticed for a couple 
of decades simply because the wrong name never appeared anywhere in 
public until it eventually cropped up on a planning application. 
Getting the name corrected wasn't an easy task, because of the length 
of time it had been wrongly recorded, but we did eventually 

[OSM-talk-fr] Tagrequest :: "Nouveau lieu de loisirs et d’animations familiales"

[Jacques Lavignotte]

Ce noeud

https://www.openstreetmap.org/node/7701888072

"Nouveau lieu de loisirs et d’animations familiales"

selon :

https://www.lanouvellerepublique.fr/vienne/a-biard-ce-soir-le-mana-ouvre-ses-portes-en-fanfare

comme on y joue à la pétanque et qu'il y'a un panneau de basket j'ai mis 
« leisure=pitch » en attendant vos conseils avisés et que j'y aille ce 
soir boire une 


Merci,

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [Talk-GB] The curious case of USRN 20602512

[James Derrick]

Hi,

On 10/07/2020 11:27, Mark Goodge wrote:
So this is a bit of a warning, really, for the open mapping community. 
Although the open data release of USRN ids and coordinates is welcome, 
don't be tempted to look up street names on the street list published, 
with a restrictive licence, on https://www.findmystreet.co.uk and then 
copy them to our own data. Because it simply isn't reliable enough as 
a guide to actual usage, even if it is what the "official" name of the 
road may be. Stick to OS Open Data and local knowledge. 


Thanks - that's an interesting and informative tale about 'canonical' 
sources being sourced by human beings from complex and contradictory data.


Some years ago, I remember being rather surprised investigating 
differences between my own surveys and OS open data using ITO tools. 
After double checking the 'ground truth', OSM is closer to reality than 
OS in several places around my area - perhaps 3 diffs across a 45k 
population town (Cramlington, NE23).


Geography and human society is more complex with the same space being 
called many things over time, and by different groups.


How many small towns didn't have a 'High Street' until an OS surveyor 
first visited it and wrote a name down?


How many 19th century terraces originally had the buildings named, 
rather than the surrounding streets?


Working in telecoms, I understand the benefits of a UPRN / USRN, however 
as a geographer they still feel a bit like a more precise version of 
'High Street'.


I still added U*RN tags to my local area - like a 21st century alt_name 
tag! :-)



James
--
James Derrick
li...@jamesderrick.org, Cramlington, England
I wouldn't be a volunteer if you paid me...
https://www.openstreetmap.org/user/James%20Derrick


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

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[David Marín Carreño]

Yo uniría esta reclamación con el tema de Gibraltar, ya que el caso es
exactamente el mismo, y la resolución debería ser igual: aguas
territoriales reclamadas, pero no reconocidas por una parte.

Así, si la política o normas de OSM nos quita las aguas territoriales de
Ceuta y Melilla, al menos recuperaríamos las de Gibraltar ;-D

--
David Marín Carreño 



El vie., 10 jul. 2020 a las 12:13, Alejandro Moreno ()
escribió:

> El tema parece que se discutió hace unos años en
> https://forum.openstreetmap.org/viewtopic.php?pid=606038#p606038
>
> El vie., 10 jul. 2020 a las 11:54, Andy Townsend ()
> escribió:
>
>> On 10/07/2020 09:38, Miguel Sevilla-Callejo wrote:
>> > Buscando por aquella vez que "metí las narices en el caso" [1]
>> > encontré este changset [2]
>> > Por algún lado debe estar mi interacción con la gente que maneja los
>> > límites internacionales.
>> >
>> > [1] https://tinyurl.com/y9n387qk
>> >
>> > [2] https://www.openstreetmap.org/changeset/49804213
>>
>> Also see https://overpass-api.de/achavi/?changeset=49804213
>>
>> Best Regards,
>>
>> Andy
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Suppression *covid19=*

[Philippe Verdy]

Le jeu. 9 juil. 2020 à 20:09, deuzeffe  a écrit :

> Le 08/07/2020 à 20:46, Philippe Verdy a écrit :
>
> Bonjour également,
> (voir https://fr.wikipedia.org/wiki/N%C3%A9tiquette#Politesse )
>
> /snip le top-posting (cf
> https://fr.wikipedia.org/wiki/TOFU_(Usenet_et_Internet) ) non seulement
> impoli mais constituant une réponse totalement hors-sujet quant à la
> question originelle.
>

/SNIP ta réponse... je n'ai pas été "impoli" envers qui que ce soit...
Et Wikipedia n'est pas une référence sur le sujet.
Ma réponse était parfaitement cadrée sur le sujet... Puisque l'auteur
initial souhaitait "virer" les tags qu'ils jugent maintenant "inutiles"
alors que rien n'est fini, bien au contraire, ce sont jute les conditions
locales d'usage qui peuvent évoluer et revenir. c'est bête de gâcher le
patient travail des autres par une suppression massive malvenue pour devoir
tout refaire ensuite.
Il vaut mieux mettre un tag sur les zones où les restrictions sont
(temporairement) levées.
Au_joud'hui les restrictions de voyage sont levées avec une quinzaine de
pays hors UE (dont 2 en Europe, Serbie et Monténégro, mais pas du tout en
Amérique: le Canada est théoriquement ouvert, en attendant que lui de son
côté rouvre ses liaisons extérieures, ce qui n'est pas fait étant donné la
situation chez son voisin aux USA).
Le reconfinement apparait déjà en Mayenne même si le dépistage y est
organisé.
On sait que le virus va très vite (plus vite que nous)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] The curious case of USRN 20602512

[Mark Goodge]

Apologies for the long read, but this may be interesting to some folk. 
This follows on from my earlier response to Kai Michael Poppe about 
"Fairfield Road" in Ealing.


On 04/07/2020 12:02, I wrote:


To find the USRN of the path, you need to use the lookup tables supplied 
by OS. Doing that, we find that the associated USRN is 20602512.


Now, there's no open data source which will directly tell you the name 
of a USRN (at least, not until we start putting them into OSM). The long 
way of doing so is to find the matching LineString in OS OpenMap Local, 
and see what name it has there.


However, it can be done directly via a non-open source. If you go to 
https://www.findmystreet.co.uk/map and zoom in on the location, then 
click the street to bring up the USRN details, it will give the name 
(and also confirm that the USRN from the OS lookup table is correct). Or 
use the search box and search for USRN 20602512.


 From an OSM point of view, that would normally be a dead end. Even if 
you can view the information on a non-open source, you can't incorporate 
it into OSM. However, in this case, we already have an abbreviated name 
from an open source. So all we are learning from the closed source is 
the full text of the abbreviation. Whether that makes it acceptable to 
include the full name into OSM is a matter of debate. I'll leave that 
decision up to others, but, for reference, the name of the street is 
Fairfield Road.


I've been doing a bit more research in this, as it piqued my interest. 
And the results are a little surprising.


For a start, USRN 20602512 doesn't match Fairfield Road in OS LocalMap 
Open. In fact, there's no Fairfield Road anywhere near there in OSLMO. 
Matching the coordinates indicates that, as far as OS is concerned, it's 
a part of Southdown Avenue. That's not particularly unusual, access 
roads off named streets often don't have a name of their own, they're 
either completely unnamed or share the name of their parent street.


However, I did wonder whether this might just be a limitation on OS Open 
Data, and whether MasterMap might actually include the name. That's not 
reusable in OSM, of course, but it might help point to an open source 
that does contain it.


But it seems that even MasterMap doesn't have that name. You can check 
that by looking at Ealing's online GIS website:


http://maps.ealing.gov.uk/Webreports/Planning/Planning.html

This is a planning application map, but it's just a window into their 
GIS system and you can turn off the planning layers. Anyway, zoom all 
the way in to the street in question - I can't give you a persistent 
link, but it's just above the LA boundary in the bottom middle of the 
map - and... it still has no name. At the highest zoom level, this is 
MasterMap, and every named object has its name displayed. But there's no 
name here.


Google, also, knows nothing of a Fairfield Road here. Using the Maps API 
to query the coordinates of USRN 20602512, we either get Southdown 
Avenue, again, or Boston Gardens, which is the postal address of 
buildings facing Boston Road. You can see that name on the road sign via 
Google Streetview:


https://goo.gl/maps/KGLbRC75mQw43PCV6

So, it seems that Fairfield Gardens isn't known to either OS or Google. 
It is shown (in abbreviated form) on streetmap.co.uk, but at that zoom 
level, in London, that's based on the Bartholomew A-Z maps rather than OS.


Given that, we can't include the name "Fairfield Road" in OSM as it's 
only available from non-open sources. But even those non-open sources 
don't agree on the name. That seems to me to lead to two possibilities:


1. It doesn't exist at all. It's just a map trap designed to catch out 
unwary copyright infringers. That's certainly a possibility, and A-Z 
maps are known to use those. But that doesn't explain its presence in 
the USRN database.


2. The USRN name is wrong, but that error has propagated to the A-Z maps.

Personally, I think that the second option is the most likely. And, if 
so, it wouldn't be the only error in USRN. One of the things I had to 
deal with a few years ago, in my capacity as a district councillor, was 
a country lane in my ward that had the wrong name assigned to it in 
USRN. After a bit of investigation, we concluded that it had simply been 
a transcription error back in the late 90s when the local gazetteer was 
first digitised, but it had gone unnoticed for a couple of decades 
simply because the wrong name never appeared anywhere in public until it 
eventually cropped up on a planning application. Getting the name 
corrected wasn't an easy task, because of the length of time it had been 
wrongly recorded, but we did eventually manage to get it sorted out and 
the correct, historic name of the lane assigned to the USRN.


But that's not the only one. The USRNs for where I grew up, out in the 
middle of the countryside in West Suffolk, are listed as either "Poultry 
Road" or "Sedge Fen" in the USRN database. You can 

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[Alejandro Moreno]

El tema parece que se discutió hace unos años en
https://forum.openstreetmap.org/viewtopic.php?pid=606038#p606038

El vie., 10 jul. 2020 a las 11:54, Andy Townsend ()
escribió:

> On 10/07/2020 09:38, Miguel Sevilla-Callejo wrote:
> > Buscando por aquella vez que "metí las narices en el caso" [1]
> > encontré este changset [2]
> > Por algún lado debe estar mi interacción con la gente que maneja los
> > límites internacionales.
> >
> > [1] https://tinyurl.com/y9n387qk
> >
> > [2] https://www.openstreetmap.org/changeset/49804213
>
> Also see https://overpass-api.de/achavi/?changeset=49804213
>
> Best Regards,
>
> Andy
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[Andy Townsend]

On 10/07/2020 09:38, Miguel Sevilla-Callejo wrote:
Buscando por aquella vez que "metí las narices en el caso" [1] 
encontré este changset [2]
Por algún lado debe estar mi interacción con la gente que maneja los 
límites internacionales.


[1] https://tinyurl.com/y9n387qk

[2] https://www.openstreetmap.org/changeset/49804213


Also see https://overpass-api.de/achavi/?changeset=49804213

Best Regards,

Andy


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

Re: [Talk-it] Fwd: [OSM-talk] expanded outdoor map on www.freemap.sk/?layers=X

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2020, at 09:55, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
>> ma per aree meno dense, per esempio in montagna, potrebbe essere 
>> un’alternativa interessante.
>> 
>> Ciao Martin 
>> 
> 
> grazie della segnalazione.


dimenticavo (l’avrete visto) interessante anche perché visualizza le route 
hiking, curve di livello, ombreggiature, consente esportazioni per la stampa, 
retina tiles, e quant’altro. C’è anche un app.

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

Re: [OSM-talk-fr] Test mission Pic4Review "Passage piéton en fauteuil roulant"

[Éric Gillet]

Le 09/07/2020 à 14:21, Percherie OnDaNet a écrit :
La mission "Passages piéton en fauteuil roulant" : 
https://pic4review.pavie.info/#/mission/1103


Avant de la proposer comme modèle sur Pic4Review, pouvez-vous vérifier 
si je n'ai pas fait de coquille dans les tags utilisé ? Vous pouvez 
les consulter quand vous dupliquez la mission pour votre zone. Au 
besoin je peut les énumérer ici mais si je peut éviter de polluer la 
liste.


Petit détail, mais je pense qu'il faudrait homogénéiser les termes entre 
les boutons de la revue et sa présentation (exemple "Parfait"="Aucune 
restriction").


Autre soucis mais sûrement plus général à Pic4Review, il n'indique pas 
la source (image Mapillary par ex.) dans les changesets.



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

Re: [OSM-talk-fr] Le député Éric Bothorel investi d’une mission sur la politique de la donnée et des codes sources

[Christian Quest]

Le 10/07/2020 à 09:59, François Lacombe a écrit :


Le ven. 10 juil. 2020 à 09:45, Christian Quest 
mailto:cqu...@openstreetmap.fr>> a écrit :




Je n'ai pas encore pu trouver une copie de la lettre de mission, pour
savoir exactement de quoi il retourne...

Je trouve par exemple étonnant qu'on parle d'ouverture "opportune",
alors que c'est la règle par défaut.


C'est bien un point à discuter.
Laure de la Raudière peut aussi être intéressée.

Vu l'ambiance actuelle il est possible que cette mission puisse être 
là pour freiner le mouvement.

C'est en ce sens que je parlais de vaccin.

Bonne journée

François



La tendance de ce gouvernement est effectivement assez tiède sur 
l'ouverture, on voit souvent le mot "partage" à la place ce qui n'est 
pas du tout la même chose.


J'ai écrit à Eric Bothorel, plutôt en mode offre d'appui pour la mission 
vues mes multiples casquettes actuelles et passées (y compris OSM bien sûr).



--
Christian Quest - OpenStreetMap France

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

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[Miguel Sevilla-Callejo]

Buscando por aquella vez que "metí las narices en el caso" [1] encontré
este changset [2]
Por algún lado debe estar mi interacción con la gente que maneja los
límites internacionales.

[1] https://tinyurl.com/y9n387qk

[2] https://www.openstreetmap.org/changeset/49804213

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 10 Jul 2020 at 10:27, Miguel Sevilla-Callejo 
wrote:

> Gracias por el enlace a la Wiki Alejandro, justo me faltó eso en mi
> mensaje.
>
> David, dejando a un lado las aguas de Gibraltar, te animo a abrir un hilo
> al respecto si es necesario, aunque si puedo entender lo de que España
> patrulla la zona de Ceuta y Melilla... ¿Qué límites aplicamos?¿Dónde
> ponemos la línea? Por lo visto este es el problema de base... cómo lanzar
> la línea de separación entre unos y otros.
>
> Es un tema a resolver, sin duda, pero como dije antes, hay un
> procedimiento y si alguien se anima a iniciarlo bienvenido sea, pero
> insisto que, por lo que a mi respecta, me interesan más las líneas reales
> que las imaginarias.
>
> Un saludo
>
> Miguel
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> On Fri, 10 Jul 2020 at 07:14, David Marín Carreño 
> wrote:
>
>> Según el documento con las normas que puso la OSMF:
>> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf
>>
>> The OpenStreetMap community operates under the “on the ground” principle,
>>> recordingwhat is actually currently used in a particular area, giving
>>> pre­eminence to data collectedin­situ. This is generally what is used on
>>> our main example map athttp://www.openstreetmap.org.
>>>
>>
>> Vamos, que si quien ejerce el control de manera efectiva sobre esas aguas
>> es España, el mapa debiera mostrarlas como españolas _por defecto_.
>> Exactamente lo mismo que pasa con Gibraltar: según el tratado de Utrecht
>> las únicas aguas británicas serían las del puerto, pero son ellos los que
>> patrullan su parte de la bahía de Algeciras así que así aparece en el mapa
>> y me parece bien según la norma anterior, aunque pueda tener legitimidad
>> mostrar esas aguas como españolas.
>>
>> Otro tema es el etiquetado extra para mostrar esas aguas como "territorio
>> en disputa", etc.
>>
>> Lo que no me gusta nada es la asimetría. Si Ceuta o Melilla no tienen
>> aguas jurisdiccionales "por defecto", es incluso menos justificado mostrar
>> aguas jurisdiccionales en Gibraltar.
>> --
>> David Marín Carreño 
>>
>>
>>
>> El jue., 9 jul. 2020 a las 22:42, Alejandro S. ()
>> escribió:
>>
>>> Tal vez sirva de guía:
>>> https://wiki.openstreetmap.org/wiki/Disputed_territories
>>>
>>> On Thu, Jul 9, 2020, 21:59 Nicolás Vieites Sueiro 
>>> wrote:
>>>
 Buenas tardes,

 Por lo que veo, no es la primera vez, ni será la última en la que habrá
 problemas con la tenencia de un territorio entre países y, en cambio, en
 OSM aún no sabemos muy bien como gestionar estos casos.
 A mi parecer debería existir una forma de mapear zonas que se
 encuentran en disputa entre dos países. Se me ocurren dos cosas:

 1.- Crear un tipo de boundary específico para zonas disputadas

 2.- Añadir una zona a la relación de los países que mantienen la
 disputa por él territorio, con un rol específico para indicar que se
 encuentra en disputa la zona.

 Pero esto ya no es algo que podamos discutir aquí, hay q llevarlo a la
 lista de tagging si no me equivoco.

 Un saludo.




 Get Outlook for Android 
 --
 *From:* Miguel Sevilla-Callejo 
 *Sent:* Thursday, July 9, 2020 8:50:18 PM
 *To:* Discusión en Español de OpenStreetMap 
 *Subject:* Re: [Talk-es] Porqué no figuran las aguas territoriales de
 Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas
 ciudades?

 Hola de nuevo,

 En una búsqueda rápida en internet me encuentro que es un tema abierto
 y sin resolución entre Marruecos y España por lo que desde OSM yo no
 tomaría partido, si a nivel internacional no se ha llegado a un acuerdo.

 En una noticia de hace ya 10 años se asegura que no hay delimitación
 clara [1] y luego en wikipedia [2] o en noticias más recientes [3] parece
 claramente que sigue existiendo una disputa.

 [1] https://elfarodeceuta.es/aguas-espanolas-de-ceuta/
 [2]
 https://es.wikipedia.org/wiki/Frontera_entre_Espa%C3%B1a_y_Marruecos
 [3]
 https://www.efe.com/efe/espana/politica/marruecos-y-espana-bajan-el-tono-en-la-polemica-de-las-aguas-territoriales/10002-4158309

 Saludos

 Miguel

 --
 *Miguel Sevilla-Callejo*
 Doctor en Geografía


 On Thu, 9 Jul 2020 at 13:34, Diego Cruz  wrote:

 Hola a todos:

 Yo tampoco me he metido a investigar sobre el tema ni a ver por qué
 están mapeadas las cosas como están, pero quizás sí que se pueda abrir un
 debate a mayor 

Re: [Talk-es] Porqué no figuran las aguas territoriales de Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas ciudades?

[Miguel Sevilla-Callejo]

Gracias por el enlace a la Wiki Alejandro, justo me faltó eso en mi mensaje.

David, dejando a un lado las aguas de Gibraltar, te animo a abrir un hilo
al respecto si es necesario, aunque si puedo entender lo de que España
patrulla la zona de Ceuta y Melilla... ¿Qué límites aplicamos?¿Dónde
ponemos la línea? Por lo visto este es el problema de base... cómo lanzar
la línea de separación entre unos y otros.

Es un tema a resolver, sin duda, pero como dije antes, hay un procedimiento
y si alguien se anima a iniciarlo bienvenido sea, pero insisto que, por lo
que a mi respecta, me interesan más las líneas reales que las imaginarias.

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 10 Jul 2020 at 07:14, David Marín Carreño  wrote:

> Según el documento con las normas que puso la OSMF:
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf
>
> The OpenStreetMap community operates under the “on the ground” principle,
>> recordingwhat is actually currently used in a particular area, giving
>> pre­eminence to data collectedin­situ. This is generally what is used on
>> our main example map athttp://www.openstreetmap.org.
>>
>
> Vamos, que si quien ejerce el control de manera efectiva sobre esas aguas
> es España, el mapa debiera mostrarlas como españolas _por defecto_.
> Exactamente lo mismo que pasa con Gibraltar: según el tratado de Utrecht
> las únicas aguas británicas serían las del puerto, pero son ellos los que
> patrullan su parte de la bahía de Algeciras así que así aparece en el mapa
> y me parece bien según la norma anterior, aunque pueda tener legitimidad
> mostrar esas aguas como españolas.
>
> Otro tema es el etiquetado extra para mostrar esas aguas como "territorio
> en disputa", etc.
>
> Lo que no me gusta nada es la asimetría. Si Ceuta o Melilla no tienen
> aguas jurisdiccionales "por defecto", es incluso menos justificado mostrar
> aguas jurisdiccionales en Gibraltar.
> --
> David Marín Carreño 
>
>
>
> El jue., 9 jul. 2020 a las 22:42, Alejandro S. ()
> escribió:
>
>> Tal vez sirva de guía:
>> https://wiki.openstreetmap.org/wiki/Disputed_territories
>>
>> On Thu, Jul 9, 2020, 21:59 Nicolás Vieites Sueiro 
>> wrote:
>>
>>> Buenas tardes,
>>>
>>> Por lo que veo, no es la primera vez, ni será la última en la que habrá
>>> problemas con la tenencia de un territorio entre países y, en cambio, en
>>> OSM aún no sabemos muy bien como gestionar estos casos.
>>> A mi parecer debería existir una forma de mapear zonas que se encuentran
>>> en disputa entre dos países. Se me ocurren dos cosas:
>>>
>>> 1.- Crear un tipo de boundary específico para zonas disputadas
>>>
>>> 2.- Añadir una zona a la relación de los países que mantienen la disputa
>>> por él territorio, con un rol específico para indicar que se encuentra en
>>> disputa la zona.
>>>
>>> Pero esto ya no es algo que podamos discutir aquí, hay q llevarlo a la
>>> lista de tagging si no me equivoco.
>>>
>>> Un saludo.
>>>
>>>
>>>
>>>
>>> Get Outlook for Android 
>>> --
>>> *From:* Miguel Sevilla-Callejo 
>>> *Sent:* Thursday, July 9, 2020 8:50:18 PM
>>> *To:* Discusión en Español de OpenStreetMap 
>>> *Subject:* Re: [Talk-es] Porqué no figuran las aguas territoriales de
>>> Ceuta y Melilla y la frontera de Marruecos está sobre las costas de esas
>>> ciudades?
>>>
>>> Hola de nuevo,
>>>
>>> En una búsqueda rápida en internet me encuentro que es un tema abierto y
>>> sin resolución entre Marruecos y España por lo que desde OSM yo no tomaría
>>> partido, si a nivel internacional no se ha llegado a un acuerdo.
>>>
>>> En una noticia de hace ya 10 años se asegura que no hay delimitación
>>> clara [1] y luego en wikipedia [2] o en noticias más recientes [3] parece
>>> claramente que sigue existiendo una disputa.
>>>
>>> [1] https://elfarodeceuta.es/aguas-espanolas-de-ceuta/
>>> [2] https://es.wikipedia.org/wiki/Frontera_entre_Espa%C3%B1a_y_Marruecos
>>> [3]
>>> https://www.efe.com/efe/espana/politica/marruecos-y-espana-bajan-el-tono-en-la-polemica-de-las-aguas-territoriales/10002-4158309
>>>
>>> Saludos
>>>
>>> Miguel
>>>
>>> --
>>> *Miguel Sevilla-Callejo*
>>> Doctor en Geografía
>>>
>>>
>>> On Thu, 9 Jul 2020 at 13:34, Diego Cruz  wrote:
>>>
>>> Hola a todos:
>>>
>>> Yo tampoco me he metido a investigar sobre el tema ni a ver por qué
>>> están mapeadas las cosas como están, pero quizás sí que se pueda abrir un
>>> debate a mayor nivel sin necesidad de estar constituidos primero como un
>>> capítulo local (cosa que desde luego vendría bien para muchos asuntos).
>>>
>>> Es decir, puede plantearse en términos generales qué hacer con las aguas
>>> que están disputadas por varios países, algo que afecta a todo el mundo y
>>> no solo a la comunidad española.
>>>
>>> Aquí se da la incongruencia de que no hay tratados ni con Marruecos ni
>>> con el Reino Unido, pero las aguas en OSM figuran como pertenecientes a
>>> estos países. Si no hay acuerdos 

Re: [OSM-talk-fr] Salle de spectacle / salle de réceptions

[Brice]

Le 29/06/2020 à 22:03, Yves P. a écrit :

Concernant ce tag amenity=events_venue, je ne le connaissais pas et 
pour cause, c'est une ébauche. 

Ok.

Honnêtement pour moi ca ferait doublon avec community_centre sauf si 
c'est un lieu dédié à ca, ce qui est rarement le cas, sauf peut-être 
chez des prestataires privés.

Il me semble que le terme vient des anglo-saxons.
Venue : the place where something happens, especially an organized event 
such as a concert, conference, or sports competition: the club is the 
city's main venue for live music.


Mais il me semble que ça désigne un lieu comme les Zénith. 
https://en.wikipedia.org/w/index.php?title=Music_venue


Plus précisément qu'un lieu pour spectacles, c'est bien un lieu pour 
*réceptions*, à mon sens ; je l'ai utilisé pour ceci :

https://www.openstreetmap.org/node/7070741739

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

[Talk-it] Presentazione progetto "ViaLibera?!"

[Lorenzo Stucchi]

Ciao a tutte e tutti,

volevo comunicarvi che nei prossimi mesi inizierà le attività di mappatura per 
il progetto "ViaLibera?! - Progetto di mappatura e valutazione 
dell’accessibilità del Municipio 9 di Milano",

Il lavoro di mappatura verrà svolto dal mese di Settembre e sarà diviso in due 
principali attività: una mappatura continuativa che vedrà la partecipazione di 
una classe quinta del Liceo Scientifico Luigi Cremona di Milano e 
l'organizzazione di eventi di mappatura collaborativa per la cittadinanza 
quando ciò sarà consentito.

E' stata creata una pagina wiki [1] per introdurre il progetto. La pagina è 
ancora in costruzione per via delle incertezze sul calendario dei futuri 
eventi. 

La sezione dei tag e degli elementi che verranno mappati è aperta per qualsiasi 
suggerimento e consiglio. Gli elementi sono stati selezionati in collaborazione 
con le associazioni partner del progetto e dai progetti su questo tema già 
esistenti in OSM (es. PEBAthon a Padova).

Il progetto focalizzerà la mappatura in alcune aree di particolare interesse 
nel Municipio 9 che verranno riportate nella pagina wiki.

Grazie per l'attenzione e grazie a chi vorrà collaborare.

Saluti,
Lorenzo Stucchi
Research Fellow, Politecnico di Milano

[1] https://wiki.openstreetmap.org/wiki/ViaLibera

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

Re: [OSM-talk-fr] Le député Éric Bothorel investi d’une mission sur la politique de la donnée et des codes sources

[François Lacombe]

Le ven. 10 juil. 2020 à 09:45, Christian Quest  a
écrit :

>
>
> Je n'ai pas encore pu trouver une copie de la lettre de mission, pour
> savoir exactement de quoi il retourne...
>
> Je trouve par exemple étonnant qu'on parle d'ouverture "opportune",
> alors que c'est la règle par défaut.
>

C'est bien un point à discuter.
Laure de la Raudière peut aussi être intéressée.

Vu l'ambiance actuelle il est possible que cette mission puisse être là
pour freiner le mouvement.
C'est en ce sens que je parlais de vaccin.

Bonne journée

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

Re: [Talk-it] Fwd: [OSM-talk] expanded outdoor map on www.freemap.sk/?layers=X

[liste DOT girarsi AT posteo DOT eu]

Il 09/07/20 23:23, Martin Koppenhoefer ha scritto:
> Vi segnalo che Martin Zdila ha esteso la copertura di Freemap anche su Italia.
> 
> Non è uno stile per i centri urbani:
> 
> https://www.freemap.sk/?map=14/41.898508/12.477336=X
> 
> ma per aree meno dense, per esempio in montagna, potrebbe essere 
> un’alternativa interessante.
> 
> Ciao Martin 
> 

grazie della segnalazione.



-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] Le député Éric Bothorel investi d’une mission sur la politique de la donnée et des codes sources

[Sébastien Dinot]

- Mail original -
> Je trouve par exemple étonnant qu'on parle d'ouverture "opportune",
> alors que c'est la règle par défaut.

Le qualificatif m'a moi aussi fait tiquer. Il a comme un goût de rétropédalage.

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
https://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


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

Re: [OSM-talk-fr] Le député Éric Bothorel investi d’une mission sur la politique de la donnée et des codes sources

[Christian Quest]

Le 10/07/2020 à 07:42, Jean-Christophe Becquet a écrit :

Bonjour,

Le député Éric Bothorel est investi d’une mission sur la politique de
la donnée et des codes sources.
https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT42025804

Voir par exemple : [Actualités du droit ] Ouverture des données et des
codes sources publics : l’État souhaite accélérer
https://www.actualitesdudroit.fr/browse/tech-droit/donnees/27986/ouverture-des-donnees-et-des-codes-sources-publics-l-etat-souhaite-accelerer

Extrait : « la mission devra :

  - identifier, secteur par secteur, les données et les codes dont
l’ouverture serait opportune, en indiquant la méthodologie préconisée ;
  - étudier l’opportunité d’établir un cadre juridique générique
transversal pour l’ouverture, le partage et l’exploitation des données
d’intérêt général ou s’il est, au contraire, préférable de déverrouiller
la situation par une approche juridique sectorielle ;
  - réfléchir à une gouvernance de ces données. »


La mission confiée à Eric Bothorel sur l'ouverture des données et des
codes source des logiciels de l'administration a un périmètre très large
(données publiques, codes publics, données privées d'intérêt général).
Il devra rendre ses conclusions mi-décembre 2020.
https://twitter.com/emile_marzolf/status/1275392416384778243

Pilotage des données et des codes sources, une mission temporaire
"M. Eric BOTHOREL, député, est, en application de l'article LO 144 du
code électoral susvisé, chargé d'une mission temporaire ayant pour objet
la politique de la donnée et des codes sources."
https://mastodon.etalab.gouv.fr/@nschont/104392566726310669

Bonne journée

JCB



Je n'ai pas encore pu trouver une copie de la lettre de mission, pour 
savoir exactement de quoi il retourne...


Je trouve par exemple étonnant qu'on parle d'ouverture "opportune", 
alors que c'est la règle par défaut.


On risque encore tourner autour du pot plutôt que d'appliquer les textes 
existants.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Tag Info France en panne ?

[Christian Quest]

Le 09/07/2020 à 23:36, Christian Rogel a écrit :

Je n’ai vu nulle part d’indication sur une panne de TagInfo Fr inaccessible 
depuis 3 jours.
Au niveau mondial, pas souci.

Qui a des infos ?


Christian R.


Accessible pour moi, par contre, les chiffres n'ont pas l'air cohérents...

https://taginfo.openstreetmap.fr/tags a des chiffres qui m'ont l'air 
corrects, dès qu'on demande le détail, tout est à 0...



Issue ouverte sur: https://github.com/osm-fr/infrastructure/issues/214


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] expanded outdoor map on www.freemap.sk/?layers=X

[Martin Ždila]

On Fri, Jul 10, 2020 at 9:10 AM THEVENON Julien 
wrote:

>
> Very nice !
>

thank you


> Hope to see France covered one day, my holiday destination is not so far
> from the coverage limit :-(
>

The limit is dictated by our hardware. But in the future we may expand even
more :-)

-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] expanded outdoor map on www.freemap.sk/?layers=X

[THEVENON Julien via talk]

Le jeudi 9 juillet 2020 à 21:41:06 UTC+2, Martin Ždila 
 a écrit : 

Hello,

> Let me announce that we have expanded our outdoor map to more (european) 
> countries. You can see it in action at www.freemap.sk/?layers=X

> Most of it is the work of a single person (me) doing it in his free time and 
> therefore some features may not be 100% user friendly.

Very nice !
Hope to see France covered one day, my holiday destination is not so far from 
the coverage limit :-(

Cheers
Julien

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