[Talk-bo] Actualizaron el editor iD (2.18)

[Marco Antonio]

Hola,

En esta última actualización del editor web iD 2.18 hay cosas interesantes:

* tiene soporte para dispositivos móviles (tabletas), aún no probé
* seleccionar varios elementos y editar algunos datos todos a la vez
* añadieron el validador OSMOSE de la comunidad francesa, que revisa
cosas interesantes que a veces se nos va editando, ya arreglé algunos
cosillas en vinto, cochabamba
* varios elementos reconocidos por Mapillary
* cuando alejas el mapa, no carga los datos pero si se ve el mapa de
mapbox con mejoras para identificar carreteras y barrios/pueblos

no se olviden ocultar los boundaries antes de empezar a editar para
que no hagamos desastres!

los cambios →
https://github.com/openstreetmap/iD/blob/develop/CHANGELOG.md

Abrazos,

Marco Antonio

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

[Talk-GB] Another UPRN/ oddity

[Andy Mabbett]

Here's a good one...

I know the street at:

   
https://www.openstreetmap.org/?mlat=52.54633=-1.91892#map=19/52.54633/-1.91892

which is a side-loop off the Queslett Road dual carriageway (and,
indeed is the original alignment of Queslett Road, before the dual
carriageway was built), as being also "Queslett Road". OSM sensibly
agrees with me, as does Royal Mail's address/postcode-finder. As did a
friend who lived there, many years ago.

OSM has it as most (but not the western extremity) of this way:

   https://www.openstreetmap.org/way/21585974

all of this one: (under the M6 motorway)

   https://www.openstreetmap.org/way/400244529

and the southern segment only, of this one:

   https://www.openstreetmap.org/way/400244530#map=18/52.54747/-1.91762:

The house nearest to my marker is 229 Queslett Road. Its UPRN is
100070487637; and the government flood warning service also says its
address is Queslett Road:

   
https://flood-warning-information.service.gov.uk/long-term-flood-risk/risk?address=100070487637

But the USRN for the loop is given on "Find My Street" as 2708337,
which is Booths Lane.

I can't link to that, because...  well, I don't know why. You can look
it u by zooming and scrolling to it via:

   https://www.findmystreet.co.uk/

Google Maps also calls it Booths Lane.

OSM says Booths Lane only starts with:

https://www.openstreetmap.org/way/400244530#map=18/52.54747/-1.91762

and my local knowledge concurs.

AFAICT, there are no street name plates on that stretch of road.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-GB] Scheduled Monument

[Dave Love]

On Wed, 2020-07-15 at 10:18 +0100, Tony OSM wrote:

> For a building or similar I presently use
> 
> HE_ref=1072653
> heritage=2
> heritage:operator= Historic England
> historic= heritage
> listed_status=Grade II
> name= War Memorial Gateway to Astley Park
> barrier=gate
> start_date= mid C19
> website=
> https://historicengland.org.uk/listing/the-list/list-entry/1072653

I forgot to comment before:  From a maintenance point of view, is it a
good idea to add redundant data (that I assume are implied by HE_ref)?

Also:

On Thu, 2020-07-16 at 14:10 +0100, Tony OSM wrote:
> Yes, maintenance when things change is an issue.
> 
> I've looked at taginfo listed_status and found several variations 
> for 
> Scheduled Monument, Grade(value)
> 
> I plan to do several things if there are no objections
> 
> 1. update wiki listed_status to show the capitalised values
> Scheduled 
> Monument, Protected Wreck Site,
> Park and Garden, Battlefield, World Heritage Site, Certificate of 
> Immunity, Building Preservation Notice

What happens to, say, a park/garden with a grade, then?

Straying a bit from the topic a bit, perhaps it's worth adding
something about adding listed things that may not be obvious to
everyone.  If you find in the HE listings a building (say) you don't
already know and want to tag it, presumably it's a problem that you
can't just match the position on their OS maps to OSM.  I assume you
need to take the listed grid reference and just use that (which you
probably can't with curtilages etc. or a monument like an ancient
ditch, though that's likely on NLS 1:1).  The wiki could use info
about converting grid references too, unless I missed it.

To avoid problems, I've found https://britishlistedbuildings.co.uk
useful, as it actually marks the location on OSM, with the grid
reference converted to latitude/longitude if you do need it, like when
the building isn't mapped.  Also, if you're specifically interested in
listings in an area the points on the map are helpful, similarly to
something like 
https://maps.cheltenham.gov.uk/map/Aurora.svc/run?script=\Aurora\CBC+ListedBuildings.AuroraScript%24=1762328048=always_Id=FindListedBuilding
 which presumably is also not usable, specifically not for the
conservation areas and the local listings.



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

Re: [Talk-GB] Surveying rural buildings

[Dave Love]

On Mon, 2020-07-20 at 11:29 +0100, Nick wrote:
> Dear all
> 
> I have been mapping a few properties using Bing maps with local 
> knowledge supplemented by some physical measuring (tape measure or 
> simply pacing). I now want to ramp up my mapping but the challenge 
> especially in rural areas is that sometimes the outline of a building
> is 
> not clear - either obscured (e.g. trees) or unclear (e.g. decking or
> car 
> ports). Also some aerial imagery is offset. Also, most of the
> properties 
> are not along public roads. So my question is what are the preferred 
> methods for surveying that others are using?

I don't know about preferred, and it sounds as if you want something
better, but is OS VectorMapLocal any use?  It gives the impression of
being machine-derived from imagery (probably not as well as "osmai" in
JOSM), and needs significant tidying up using good imagery if you care
to do it, but it generally gives a good indication of buildings'
presence, at least.  It definitely won't help with car ports etc.  It
would be interesting to know if it does show buildings that are
obscured in imagery.  I've used it in built-up areas, and I don't
remember relevant cases; in one with trees that I remember checking, it
wasn't recent enough anyway.

I don't think VectorMapLocal is actually listed on the wiki, and it
could do with some notes on using it.  It's definitely made adding
buildings in urban areas easier since I discovered it (from a reference
on a web site using it, not OSM info!).  Then UPRN and land registry
data seem to be useful for splitting building outlines plausibly to aid
address surveys.

> I guess at the back of my mind is what do people perceive as the
> purpose of mapping (hope I have not opened a can of worms).

I see the purpose of adding buildings and then address information
(especially postcodes) as allowing you to find them using the map for
navigation.  Your mileage may vary, so to speak.


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

[OSM-talk-ie] Fwd: UPRN tag proposal page

[Rob Nickerson]

Hi all,

There has been a release of some additional Ordnance Survey open data over
in England, Wales and Scotland - specifically the Unique Property Reference
Number (UPRN) and Unique Street Reference Number (USRN). This has led to a
question over how best to tag these values in OpenStreetMap.

Following a workshop at State of the Map, I have drafted proposal pages for
ref:GB:uprn=* and ref:GB:usrn=*. There seems to be an increase in use of
ISO two-letter country codes in ref tags, hence it's inclusion here.

As it currently stands, the data release I am aware of covers only England,
Wales and Scotland. However the UPRN and USRN allocation system is also in
use in Northern Ireland (plus Isle of Man and the Channel Islands
apparently).

The link to the proposal page for the UPRN tag is linked to in the email
below, whilst the USRN page is at
https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

Please feel free to share any comments you may have on this proposal. Also
if you are aware of open data access to the equivalent data for Northern
Ireland, I would love to hear about this so that we can include links in
the relevant wiki pages.

Best regards,
*Rob*


-- Forwarded message -
From: Rob Nickerson 
Date: Mon, 20 Jul 2020 at 22:11
Subject: UPRN tag proposal page
To: Talk-GB 


Hi all,

As discussed at the State of the Map online workshop, I took away an action
to draft a proposal page for ref:GB:uprn. This page is now up online.

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn

This is the first one of these I have done in a long time so hopefully I
got it right.

At this stage, please highlight any "red flags" that would prevent us from
moving to the voting stage. Feel free to also edit the page directly,
however I'm of the view that less is more in this case as it keeps it short
for people to read and also reduces the chance that something is added that
others do not agree with (which would be bad during the voting stage).

If there are no red flags I will move for a vote.

P.S. My thanks to Nick for drafting the initial text.
P.P.S If anyone wants to start a page for USRN, please feel free to,
otherwise I will attempt this later in the week.

Best regards,
*Rob*
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-GB] And the USRN tag proposal page

[Rob Nickerson]

As promised, here is the second tag proposal page - this time for the USRN
(Street).

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

As before, any comments welcome, especially those that would prevent us
moving to the voting stage.

P.S. Does anyone know if we need to highlight these proposals to the
tagging mailing list? If we do, could someone kindly volunteer please.

Best regards,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Surveying rural buildings

[Mateusz Konieczny via Talk-GB]

OSM building data was already used in Poland for flood preparation analysis.

It was used to supplement official building dataset, that was of much higher 
detail and accuracy, 
but also outdated (updated every N years) and was not including illegally 
constructed buildings
and buildlings not requiring planning permissions (as it was based on 
construction permits).

Jul 22, 2020, 21:37 by n...@foresters.org:

>
> Hi Mateusz
>
>
> Many thanks for your comments. 
>
>
> It would also be good to hear from others, particularly around  the 
> question of the purpose of mapping. I was thinking that my  purpose was 
> to provide other people (OSM mappers and the general  public) with the 
> information that meets their needs. The problem  is that without knowing 
> how people use the maps, identifying the  quality of the data is tricky. 
> The other challenge for people  using the maps is not knowing what the 
> quality is ~ e.g. how  comprehensively properties are mapped, precision 
> in terms of  location etc. I also wonder if the quality is good, that 
> people  might use OSM as the map to go to e.g. for Planning applications?
>
>
> Cheers
>
>
> Nick
>
> On 22/07/2020 13:20, Mateusz Konieczny  via Talk-GB wrote:
>
>>
>>
>>
>> Jul 20, 2020, 12:29 by >> n...@foresters.org>> :
>>
>>> Dear all
>>>
>>> I have been mapping a few properties using Bing maps with  local 
>>> knowledge supplemented by some physical measuring (tape  measure or 
>>> simply pacing). I now want to ramp up my mapping  but the challenge 
>>> especially in rural areas is that sometimes  the outline of a 
>>> building is not clear - either obscured (e.g.  trees) or unclear 
>>> (e.g. decking or car ports). Also some  aerial imagery is offset. 
>>> Also, most of the properties are not  along public roads. So my 
>>> question is what are the preferred  methods for surveying that 
>>> others are using?
>>>
>> Nobody replied so far so...
>>
>> I am not worried too much about geometry offset, especiallyin rural 
>> areas where
>> moving building to fix offset is usually not problematic.
>>
>>> Supplementary question, do you include or exclude  conservatories, 
>>> car ports etc. from the main structure of the  property?
>>>
>> It depends. I usually include them in case of armchairmapping of 
>> aerial images (unless there is
>> a visible gap). In mapping during survey it depends whatevercar port 
>> is part of a building structure
>> or a separate structure standing next to house.
>>
>>> I guess at the back of my mind is what do people perceive  as the 
>>> purpose of mapping (hope I have not opened a can of  worms).
>>>
>> In my case I map what is useful for projects that I use/likeor is 
>> very simple to map
>> (=available as StreetComplete quest).
>>
>> So right now I map parking lanes for >> 
>> https://github.com/dabreegster/abstreet
>> and in rural areas I tend to map hiking routes rather thanbuildings.
>>
>> ___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] Surveying rural buildings

[Nick]

Hi Mateusz

Many thanks for your comments.

It would also be good to hear from others, particularly around the 
question of the purpose of mapping. I was thinking that my purpose was 
to provide other people (OSM mappers and the general public) with the 
information that meets their needs. The problem is that without knowing 
how people use the maps, identifying the quality of the data is tricky. 
The other challenge for people using the maps is not knowing what the 
quality is ~ e.g. how comprehensively properties are mapped, precision 
in terms of location etc. I also wonder if the quality is good, that 
people might use OSM as the map to go to e.g. for Planning applications?


Cheers

Nick

On 22/07/2020 13:20, Mateusz Konieczny via Talk-GB wrote:




Jul 20, 2020, 12:29 by n...@foresters.org:

Dear all

I have been mapping a few properties using Bing maps with local
knowledge supplemented by some physical measuring (tape measure or
simply pacing). I now want to ramp up my mapping but the challenge
especially in rural areas is that sometimes the outline of a
building is not clear - either obscured (e.g. trees) or unclear
(e.g. decking or car ports). Also some aerial imagery is offset.
Also, most of the properties are not along public roads. So my
question is what are the preferred methods for surveying that
others are using?

Nobody replied so far so...

I am not worried too much about geometry offset, especially in rural 
areas where

moving building to fix offset is usually not problematic.

Supplementary question, do you include or exclude conservatories,
car ports etc. from the main structure of the property?

It depends. I usually include them in case of armchair mapping of 
aerial images (unless there is
a visible gap). In mapping during survey it depends whatever car port 
is part of a building structure

or a separate structure standing next to house.

I guess at the back of my mind is what do people perceive as the
purpose of mapping (hope I have not opened a can of worms).

In my case I map what is useful for projects that I use/like or is 
very simple to map

(=available as StreetComplete quest).

So right now I map parking lanes for 
https://github.com/dabreegster/abstreet

and in rural areas I tend to map hiking routes rather than buildings.

___
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

[OSM-talk-fr] TPU — Re : takeout Mapillary... 12To archivés

[Yves P.]

> La dernière piste identifiée... les EdgeTPU mis au point par Google. Ce sont 
> des circuits dédiés (ASIC) qui permettent de faire tourner des algos basés 
> sur des réseaux de neurones légers. Triple avantage: c'est rapide, peu 
> consommateur d'énergie (2W) et pas cher (40€ pièce). J'en ai reçu deux 
> lundi... à tester prochainement.
Je ne connaissais pas les Tensor Processing Unit 
 : bien vu :)

> Infos ici: https://coral.ai/products/m2-accelerator-bm 
> 
As-tu prévu un radiateur et/ou un ventilateur ?

> The M.2 Accelerator does not include a thermal solution to dissipate heat 
> from the system. In order to sustain maximum performance from the Edge TPU, 
> it's important that you design your system so the Edge TPU operates well 
> below the maximum Edge TPU temperature. If the Edge TPU gets too hot, it 
> slowly reduces the operating frequency and may reset to avoid permanent 
> damage.
Source : 
https://coral.ai/docs/m2/datasheet/#thermal-limit-and-operating-frequency

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

Re: [Talk-es] Ediciones del usuario jamesks

[Jorge Sanz Sanfructuoso]

Buenas.

Añadir antes de escribir que también se han comentado cosas en este
conjunto de cambios:
https://www.openstreetmap.org/changeset/87255655

Claramente nadie está pidiendo que los cambios del mapa sean perfectos, eso
es imposible que sea así siempre. Pero si hay unos mínimos que hay que
pedir. El caso de jamesks no es alguna cosa que mete mal, algo que se
equivoca, algo que hace por no saber, que tenemos un día malo. Cosas
que nos pasas a cualquiera. No tiene nada que ver con eso. Corrijo cosas
por media España y lo de jamesks nunca me lo he encontrado.

El problema es que la información de jamesks en su gran mayoría más que
dar, entorpece. En vez de ayudar lo que hace es dar aún más trabajo al
resto. Si algo está impreciso se corrigen 4, 5, 10 cosas y es más preciso o
se quitan los errores que puedan existir. El problema es que lo
de jamesks no tiene esa posibilidad en su mayoría. Es más rápido borrarlo y
hacerlo de 0. Y añadir a eso que hace ediciones enormes llenas de errores
recurrentes. Al final crea un mapa lleno de errores importantes, que nadie
es capaz de poder solucionar y es un mapa no fiable.

No es un capricho de nadie. Es una cosa que se le ha dicho de manera
recurrente y no solo desde aquí. Con bloqueo incluido por no responder
cuando se le ha comentado en este caso en China
https://www.openstreetmap.org/user_blocks/3520

Voy hacer un listado de errores recurrentes de jamesks que se le han
comentado por lo menos en su mayoría y sigue haciendolos. Se me van a
escapar algunas seguro.
-Dibujar 2 o 3 veces la misma vía una encima de otra. Aquí están 2 vías que
corregiré en unos días para que se vea mientras. Pero si vas viendo sus
ediciones hay muchas de este estilo. Además una es track, otra es senda. No
dedica 2 segundos en mirar como tiene que etiquetar lo que dibuja.
Viéndolas tiene pinta de que en una ha dibujado a mano rápidamente y la
otra a cogido Strava o alguna cosa parecida y ha metido la ruta entera como
la ha cogido el GPS, cosa que no se puede hacer. Importante tener en cuenta
lo existente cuando se edita. Sino el mapa sería un caos.
https://www.openstreetmap.org/way/815667337#map=15/41.6907/-6.1041
https://www.openstreetmap.org/way/816223498#map=15/41.6883/-6.1130

-Dibujar un montón de vías sin conexiones entre sí. Dejando los nodos casi
pegados entre ambas vías. Si no tiene las vías conexiones entre sí
existiendo la misma. El uso de esa información es bastante limitado. Ahora
mismo no tengo ningún ejemplo suyo a mano.

-Precisión. Esto ha mejorado bastante todo hay que decirlo. Cuando empecé a
verlo por donde suelo editar hace años era catastrófica la precisión. Te
podías encontrar vías a kilómetros de su posición real. Ahora no es tan
exagerado. Pone que usa muchas fuentes de ortofotos pero si las coge tan
lejos que no se ve nada da lo mismo cual use que no lo va a poder dibujar
bien. No pido que tenga 300 nodos cada vía. Pero si que los nodos se
dibujen por la traza de la misma en la medida de lo posible.

-Vías inexistentes.
Uno de los ejemplos más claros que me encontrado, pero te encuentras muchos
por el estilo. Pone incluso fuentes que ha usado PNOA y Catastro de España.
https://www.openstreetmap.org/way/817297488
Si te vas a esas fuentes se ve claramente que pasa por encima de edificios
tanto en una como en la otra.
Aquí está la foto que se ve ambas fuentes y la vía dibujada hace 1 mes.
https://photos.google.com/search/_tra_/photo/AF1QipNyz2qC9xpUVE6SBoIhqqhiN2irCWphe5o2QVHx
No se si usa fotos de hace 5 o 6 años porque es la única explicación que se
me ocurre. Pero si es así es una cosa a corregir.

-El tema de las líneas eléctricas que se ha comentado y que es por el que
creo que ha vuelto a salir a relucir todo. Pedir a jamesks que si
quiere dibujar las líneas eléctricas, entiendo que no dibuje todos los
postes. Pero por favor no lo llenes de nodos que no representan los postes
y tampoco están etiquetados como tal o nodos que se unen con carreteras.
Eso crea muchísimos errores difíciles de solucionar. Dibuja los 4 nodos
esenciales para dibujarlos que las líneas eléctricas en su mayoría son
rectas y que encima te va a llevar menos tiempo. Te ahorras tu tiempo y si
alguien quiere mejorarlo también se lo ahorras. Si alguno quiere añadirle
precisión después puede usarlo y solo tiene que mirar las fotos aéreas y
añadir los postes. Esto es un claro ejemplo de edición que tardas menos en
borrarla y dibujarla de 0 que arreglar el lío montado.

-También usa a veces etiquetados obsoletos cosa que se lo he comentado
cuando lo he visto.

Cuando empezó OSM no se tenían fotos aéreas ni nada. Se hacía lo que se
podía. Si tenías la suerte de tener un GPS para sacar trazas ya era un
logro. Pero desde entonces han cambiado mucho las cosas. Aun entonces sin
medios se tenia mas calidad que la que está dando jamesks actualmente en
muchos casos.

Todo esto creo que viene provocado por una parte por querer hacer las cosas
demasiado rápido, y por otra por seguir usando herramientas 

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Philippe Verdy]

La règle des traits d'unions pour les noms de communes ne tient plus pour
les "communes nouvelles", mais reste en vigueur pour les communes déléguées
(tant qu'il n'y a pas de fusion pleine les transformant en simples entités
géographiques historiques). Ces communes nouvelles sont des unités de
gestion administratives, comme aussi les communautés de commune (dont les
communes nouvelles sont une version "light") qui elles aussi ont des noms
sans trait d'union et souvent "à rallonge". Les communes nouvelles ne sont
pas encore péreines non plus, leur contour continue d'évoluer car leur
création ne s'est pas encore étendue partout.
Les communes nouvelles peuvent aussi naître d'une communauté de communes et
peuvent en conserver le nom. Leur code SIREN est similaire aux communautés
de communes et non aux autres communes simples et déléguées qui conservent
leur identité territoriale et juridique même si elles ne décident plus
toutes seules de leur budget alloué collectivement; ce qui est commun entre
les commuens nouvelles et autres communes simple c'est le conseil municipal
unique (qui peut aussi remplacer et reprendre l'ancien conseil
communautaire dont elles pourraient être issues). les communes nouvelles
n'ont également pas de code INSEE géograpgique à 5 chiffres qui leur soit
propre (les communes déléguées les conserve, mais il reste un usage
"toléré" du code INSEE de la commune délégué chef-lieu pour désigner la
commune nouvelle là où on ne veut distinguer aucune commune déléguée). Le
cadastre des communes nouvelles n'est également pas fusionné, pas plus que
la toponymie ou les odonymes (à moins que leur conseil en décide autrement).

Le mer. 22 juil. 2020 à 11:24, Christian Quest  a
écrit :

> Le 21/07/2020 à 20:32, Gad Jo a écrit :
> > Bonsoir,
> >
> > Suite à un changement sur quelques rues j'ai contacté le contributeur
> > comme quoi on met des tirets entre les mots généralement sur les
> > villes ou après le mot saint(e)... C'est n'est pas exhaustif bien sûr.
> >
> > Suite à sa réponse il me met le doute quand il me renvoie vers
> > l'orthographe utilisé sur wikipedia. J'aurai besoin d'information et
> > par défaut je préfère toujours me dire que j'ai tort et vérifier avant
> > de répondre
> >
> > La discutions est sur ce changeset
> > https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232
> >
> > Quelle est la réponse approprié ?
> > --
>
> On n'ajoute pas de traits d'union dans les noms (sauf là où ils sont
> normaux: Saint-Glinglin, Jean-Pierre, etc).
>
> Exception: la règle de toponymie pour les noms officiels des communes
>
> Là il y a des traits d'union partout, sauf après l'article initial:
>
> - Saint-Maur-des-Fossés
>
> - La Celle-Saint-Cloud
>
>
> Dans la zone du changeset je vois une "Rue Etienne-Gaillard", le trait
> d'union ne devrait pas y figurer.
>
> --
> 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-at] Autobahn Baukilometer

[dktue]

Hallo zusammen,

kennt ihr diesbezüglich schon autobahnkilometer.tirol? Das Projekt 
trackt den Fortschritt der Kilometersteinpflege der Autobahnen in Tirol.


Viele Grüße
dktue

[1] http://autobahnkilometer.tirol/
Am 16.07.2020 um 08:29 schrieb Philipp Kolmann:

Hallo Liste,

weiss jemand, ob es eine Liste der Koordinaten für die Autobahn 
Baukilometer gibt. Ich arbeite an einem Programm für meine Feuerwehr, 
wo bei Alarmen ein PDF ausgedruckt wird, mit der Adresse.


Für Autobahnen habe ich aber kein Mapping der Baukilometer auf 
Positionen. Ich hab mir schon den Datensatz von gip.gv.at angeschaut, 
aber da hab ich auch keine Baukilometer gefunden.


Danke für Hinweise,
lg
Philipp

___
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] takeout Mapillary... 12To archivés

[Frédéric Rodrigo]

Le 22/07/2020 à 11:48, Christian Quest a écrit :
Les photos Mapillary de notre zimmy national ont toute été 
archivées... 3.4To à lui tout seul pour 1.5M de photos.


J'en suis à 12To au total, encore 2.6To de dispo sur la grappe 
actuelle de disques.



Les dernières photos récupérées ne sont pas floutées. Pour faire 
tourner des algo d'IA, plusieurs pistes sont explorées, mais souvent 
gourmandes en ressources de calcul (et énergie), et ce même en 
utilisant un GPU à la place de CPU habituels.


La dernière piste identifiée... les EdgeTPU mis au point par Google. 
Ce sont des circuits dédiés (ASIC) qui permettent de faire tourner des 
algos basés sur des réseaux de neurones légers. Triple avantage: c'est 
rapide, peu consommateur d'énergie (2W) et pas cher (40€ pièce). J'en 
ai reçu deux lundi... à tester prochainement.


Infos ici: https://coral.ai/products/m2-accelerator-bm


Coté TPU j'en ai aussi commandé un, je l’entends encore.

J'ai déjà développé le code qui doit aller avec (sans garanti bien sûr). 
Ça peut aussi être testé sur GPU, c'est des optimisations dédié au 
runtime en fonction du matériel.


Si du monde veut aussi jouer avec l’utilisation (pas la création) de 
modèle tensorflow, on a déjà intégré ça dans


https://github.com/tyndare/blur-persons


Frédéric.



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

Re: [OSM-talk-fr] "Intégration des autoroutes" de la Guyane avec les pays voisins

[Philippe Verdy]

Aucune route importante au nord-ouest de Georgetown (Guyana) pour les
autres provinces ou vers le Venezuela?

Est-ce lié à la revendication territoriale du Venezuela sur la plus grande
partie du Guyana (le "Guyana Esqueba", la partie qui a été occupée par
l'Empire britannique sur l'ancienne colonie espagnole avant son
indépendance, à l'ouest de la vallée fluviale qui était la colonie
britannique historique alors que le reste était partie intégrante de la
plus ancienne colonie espagnole, l'est du fleuve a auissi été peu développé
hormis la zone côtière vers le suriname).
Il semble justement que l'ouest du Guyana soit très peu développé et qu'il
ne l'a quasiment pas été du tout par la colonie britannique et que depuis
le litige frontalier déjà lancé par le Venezuela contre le Royaume-Uni soit
resté en vigueur après leur départ mais cette fois envers le nouvel Etat
successeur...)
Ca peut expliquer la liaison plutôt vers le Brésil dans la vallée fluviale
développée plus tôt lors de la colonie britannique historique, le Venezuela
est aussi en litige avec le Brésil contre une partie plus au sud-ouest du
Guyana).
La route n'y est pas non plus l'axe principal de communication qui reste le
fleuve Esqueba, dont le delta avec ses mangroves est aussi une belle
réserve naturelle et aussi une zone touristique avec une petite activité de
pêche et de nombreuses excursions sur le fleuve et tout un tas de petits
ports.
Le nord de Boa Vista au Brésil, vers la revendication territoriale
brésileinne du sud du Guyana Esqueba est là aussi peu développé, transformé
en réserve naturelle, dont une route aussi difficile vers le Guyana ; je
n'ai en revanche pas vu si le Brésil avait conservé sa revendication, mais
cela semble être moins, conflictuel qu'entre Guyana et Venezuela qui
revendique les frontières de l'ancienne "Grande Colombie" avant son
démantèlement et la séparation de la Colombie, du Venezuela, du Panama, et
de Trinité et Tobago.

Le Venezuela reste encore en conflit frontalier avec les Pays-Bas
concernant Aruba et Curaçao.

Et avec le Royaume-Uni concernant la "dépendance fédérale vénézuélienne" de
"Isla de Aves" une île perdue (inhabitée) au milieu de la mer Caraïbe plus
près de l'arc antillais (il semble que la revendication britannique en tant
de dépendance de Montserrat soit abandonnée aujourd'hui), qui a été aussi
revendiquée par Antigua-et-Barbuda, et autrefois par la France comme une
dépendance de la Guadeloupe (abandonnée après le conflit franco-britannique
des Antilles durant le Premier Empire), autrefois aussi exploitée pour son
guano mais quasi abandonnée aujourd'hui, presque sans autre ressource et
mainte fois ravagée par les cyclones ; cette île est aujourd'hui une
réserve naturelle, mais les Etats-Unis s'y sont intéressés aussi car elle
est à mi-chemin de Porto-Rico/Iles vierges américaines et du Venezuela (il
est question d'y installer une station météo automatique, et une antenne
relais pour la navigation aérienne ou le suivi satellitaire ou des lanceurs
spaciaux, ou une halte de jonction pour les câbles sous-marins de
télécommunication entre Porto-Rico et le Brésil et vers les Antilles, et de
temps en temps a été émis l'idée d'un ancrer une base de lancement spacial
(sur une barge ou une plateforme pétrolière reconvertie, à un coût moindre
que les lancements depuis la Floride à Cap Canaveral, dans le passé il a
été envisagé d'en faire une base de surveillance de la navigation
sous-marine soviétique vers Cuba). Cette île est invivable mais de tels
aménagements pourraient l'artificialiser, le Venezuela se réserve le droit
de le faire et cette dépendance fédérale reste protégée de façon sommaire
en attendant. concernant les lancements spaciaux les USA collaborent avec
la France en Guyane et sinon utilisent les antennes géantes installé à
Porto Rico, cette île perdue présente moins d'intérêt aujourd'hui, autre
que pour créer une réserve naturelle marine internationale connectée aux
réserves américaines, françaises, néerlandaises à Saba, et britanniques à
Montserrat pour la protection des cétacés et des oiseaux, ainsi que les
réserves halieutiques caribéennes alors que le Golfe du Mexique est très
dégradé aussi bien aux USA qu'au Mexique (fotement pollué par les rejets et
catastrophes pétrolières, la surpêche, les rejets des fleuves américains et
mexicain et les rejets cubains. La mer Caraïbe semble cependant conserver
son attrait naturel en tant que bijou à conserver pour l'humanité.

Le mer. 22 juil. 2020 à 14:04, Adrien André via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> j'ai été contacté pour donner mon avis sur
> https://forum.openstreetmap.org/viewtopic.php?id=70063
> c.-à-d. changement de highway=primary en trunk.
>
> Le réseau routier c'est pas vraiment mon dada, il y a certainement des
> personnes bien plus averties sur cette liste :)
>
> Cela ressemble à une traduction approximative de "highway" mais, il n'y
> a pas d'*autoroute* en Guyane.
> Vraiment juste une *route 

Re: [OSM-talk-fr] takeout Mapillary... 12To archivés

[Christian Quest]

Le 22/07/2020 à 16:01, PanierAvide a écrit :
Et c'est déjà géré le fait de ne pas tout re-télécharger ? Si c'est le 
cas, on peut se permettre de faire des take-out +/- réguliers lors de 
sessions de prises de photos ?


Cordialement,

Adrien P. 



Oui (deux fois)

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Heuu justement l'erreur qui à fait que j'ai écris :-)
https://fr.m.wikipedia.org/wiki/Avenue_Pierre-de-Coubertin

Après si c'est extrêmement rare chez wikipedia mieux vaut conserver des 
ressources pour d'autres projets. C'était une réflexion à chaud.

Merci Christian pour ton retour fort clair et concis sur le changeset en 
espérant qu'il lira après les gros blocs d'explications précédent. 

Le July 22, 2020 1:48:43 PM UTC, Christian Quest  a 
écrit :
>Le 22/07/2020 à 14:57, Gad Jo a écrit :
>> Merci Christian, je pensai que je devenait fou mais c'était un 
>> contributeur néerlandais qui a pris pour argent comptant la toponymie
>
>> utilisée dans wikipedia.
>> Il aurait observé le nom des rues et des relations utilisé sur les 
>> rues il aurait eu un doute mais non... Il a fait ça un peu partout en
>
>> France.
>> C'est vraiment qu'on est des handicapés du bocal pour avoir fait la 
>> même erreur partout dans le pays :-)
>>
>> D'ailleurs est-il envisageable de remonter automatiquement ces
>erreurs 
>> de toponymie aux contributeur de wikipedia ou est-ce leur normes de 
>> nommage ? Si oui c'est dommage et complexifie la mutualisation de 
>> l'information.
>
>
>Quelle erreur sur wikipédia ?
>
>Exemple: https://fr.wikipedia.org/wiki/La_Celle-Saint-Cloud
>
>C'est ok pour moi.
>
>https://fr.m.wikipedia.org/wiki/Avenue_Pierre-de-Coubertin par contre
>ne 
>me semble pas correct vu que 
>https://fr.m.wikipedia.org/wiki/Pierre_de_Coubertin
>
>Erreur de wikipedia, la source officielle (opendata.paris.fr): "Avenue 
>Pierre de Coubertin" 
>https://opendata.paris.fr/explore/dataset/voie/table/?q=coubertin
>
>
>-- 
>Christian Quest - OpenStreetMap France

-- 
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

Re: [Talk-se] Street names overlay (Trafikverket)

[Karl Wettin]

Den tis 21 juli 2020 kl 23:27 skrev Snusmumriken <
snusmumriken.map...@runbox.com>:

> On Tue, 2020-07-21 at 21:43 +0200, Ture Pålsson wrote:
> > Nu är jag ingen mästare på JOSM-internals, men tittar man på URL:erna
> > i inställningarna, så ser det ut som om ”Street Names”-lagret kommer
> > från openstreetmap.se (som väl fortfarande är nere?), medan de andra
> > Trafikverket-lagren kommer direkt från trafikverket.
>
> Bra observation. Då blir väl följdfrågan, behöver Street Names gå via
> openstreetmap.se eller skulle man kunna byta ut det mot något som går
> direkt mot trafikverket.se?
>

Om du använder https://geo-netinfo.trafikverket.se/mapservice/wms.axd/NetInfo?FORMAT=image/png=TRUE=1.1.1=WMS=GetMap=Gatunamn=={proj}={width}={height}={bbox}>
så kommer du få den del av vägnätet som har gatunamn, inte själva
gatunamnen. Jag tror det är den enkla anledningen.

Antar eftersom openstreetmap.se varit nere ett bra tag så lär det dröja
> förän den är uppe igen.
>

Den är sakta men säkert på väg upp. Ledsen för att det tar lite tid.


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

Re: [OSM-talk-fr] sur-spécification ?

[Philippe Verdy]

Le mer. 22 juil. 2020 à 11:32, Christian Quest  a
écrit :

> Le 22/07/2020 à 00:12, osm.sanspourr...@spamgourmet.com a écrit :
> > Je vois des interdiction de faire demi-tour sur une départementale en
> > sortie de rond-point :
> >
> > https://www.openstreetmap.org/relation/11332801#map=19/47.78898/-3.47998
> >
> > Stricto sensu ce n'est pas faux mais est-ce que ça a le moindre intérêt
> ?
>
>
> Il y a sûrement une ligne continue (pas visible vu que c'est un nouveau
> rond-point qui n'est pas visible sur l'ortho), donc c'est pas faux du tout.
>

Il n'y a pas toujours de ligne continue tracée dans les 50 mètres avant le
rond-point, ni flèches de rabattement juste avant. La présence du panneau
signalant l'approche du prochain giratoire proche suffit, et de me^me on
sait qu'on vien de quitter un giratoire, donc aussi qu'aucun
demi-tour n'est permis dans les mêmes limites , tant qu'on n'a pas passé le
panneau signalant l'approche du rond point dans l'autre sens.

Un nvigateur embarqué GPS ou Grpahhopper de toute façon ne demande pas de
faire demi-tour immédiatement, mais "dès que possible", si on s'est trompé
de sortie, et dans le cas présent le dès que possible est de rejoindre le
prochain carrefour tout proche, prendre une rue tournant à gauche, et dans
ce carrefour il y a la place pour se remettre en position au début de cette
rue à gauche et en attente avant de reprendre le chemin. Il y a d'autres
opportunités aussi avec les sorties de garages au travers le trottoir, qui
peuvent servir d'épi d'arrêt temporaire (pas de stationnement évidemment)
pour faire là aussi une maneuvre permettant l'attente et l'usage
correct des clignotants (clignotant à gauche pour franchir la voir et
rejoindre l'épi de manoeuvre, arrêt temporaire changement de clignotant
vers la la droite pour la marche arrière permettant de sortir de l'épi et
s'arrêter sur la nouvelle voie dans le bon sens avant de redémarrer
normalement tout droit vers le rond-point.
En zone urbaine, les lignes continues avant le Y de l'empattement sont
rares, les distances de signalisation sont courtes. On trouve ces lignes
continues plutot en zone rurale sur des voies plus rapides que les voies
urbaines (déjà limitées à 50 ou 30 km/h...) et qui sont aussi équipée de
panneaux annonçant le prochain rond-point à 150 mètres et de flèches de
rabattment avant la ligne continue sur une distance aussi de 50 à 150
mètres (ces flèches déjà interdisent de tenter un nouveau dépassement donc
aussi leur traversée pour faire un demi-tour).
Le conducteur ne doit pas se fier aux seules indications approximatives
d'itinéraires du navigateur électronique: "dès que possible" maintient
l'obligation permanente du conducteur de respecter le code de la route et
la signalisation et d'éviter les manoeuvres dangereuses : si une collision
a lieu parce qu'un conducteur a tenté un demi-tour trop près de la
sortie d'un giratoire (à moins de 50 mètres), sa conduite sera jugée
dangereuse, il sera non seulement responsable mais aussi sanctionné, peu
importe s'il y a une ligne continue ou pas (il n'y en a pas toujours,
notamment en zone urbaine où la vitesse est déjà limitée et où "trop de
signalisation tue la signalisation": le milieu urbain est déjà riche en
panneaux et objets divers, et il vaut mieux que le conducteur observe les
autres usagers, dont les piétons qui tenteraient de traverser même hors de
l'espace protégé plus près du giratoire).

Là on chipote sur une erreur du navigateur sur une estimation de distance à
parcourir trop courte d'une centaine de mètres c'est juste quelques
secondes de conduite, rien à côté du temps d'observation nécessaire pour
effectuer un demi-tour avec prudence comme l'oblige le code de la route: le
temps de faire cette observation (en plus du temps pour se rendre compte
qu'on s'est trompé de sortie, on sera déjà loin devant.

Bref ces tags de restriction sur le noeud central du Y ne servent à rien en
pratique, et ne correspondent même à aucune signalisation à cet endroit de
jonction des voies puisque la signalisation est plus loin et que le
rond-point qu'on vient de quitter était déjà signalé comme tel de même que
la voie du Y dans l'autre sens qui est munie d'une ligne de cédez le
passage, et de meêm que les autres ralentisseurs ou ilots (ou simples plots
parfois) des passages piétons protégés, qui eux aussi matérialisent déjà ce
Y de séparation des sens.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] takeout Mapillary... 12To archivés

[PanierAvide]

Et c'est déjà géré le fait de ne pas tout re-télécharger ? Si c'est le 
cas, on peut se permettre de faire des take-out +/- réguliers lors de 
sessions de prises de photos ?


Cordialement,

Adrien P.

Le 22/07/2020 à 15:41, Christian Quest a écrit :


Le plus simple pour moi (et toi), c'est de relancer un takeout, qui ne 
prend en compte que les nouvelles photos sans tout recharger.





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

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Christian Quest]

Le 22/07/2020 à 14:57, Gad Jo a écrit :
Merci Christian, je pensai que je devenait fou mais c'était un 
contributeur néerlandais qui a pris pour argent comptant la toponymie 
utilisée dans wikipedia.
Il aurait observé le nom des rues et des relations utilisé sur les 
rues il aurait eu un doute mais non... Il a fait ça un peu partout en 
France.
C'est vraiment qu'on est des handicapés du bocal pour avoir fait la 
même erreur partout dans le pays :-)


D'ailleurs est-il envisageable de remonter automatiquement ces erreurs 
de toponymie aux contributeur de wikipedia ou est-ce leur normes de 
nommage ? Si oui c'est dommage et complexifie la mutualisation de 
l'information.



Quelle erreur sur wikipédia ?

Exemple: https://fr.wikipedia.org/wiki/La_Celle-Saint-Cloud

C'est ok pour moi.

https://fr.m.wikipedia.org/wiki/Avenue_Pierre-de-Coubertin par contre ne 
me semble pas correct vu que 
https://fr.m.wikipedia.org/wiki/Pierre_de_Coubertin


Erreur de wikipedia, la source officielle (opendata.paris.fr): "Avenue 
Pierre de Coubertin" 
https://opendata.paris.fr/explore/dataset/voie/table/?q=coubertin



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] takeout Mapillary... 12To archivés

[Christian Quest]

Le 22/07/2020 à 14:44, PanierAvide a écrit :

Bonjour,

Merci pour ce point d'étape. Je ne dois pas être le seul à continuer à 
faire des photos depuis la nouvelle de rachat et la demande de 
takeout. Y a-t'il une façon de transmettre sur ce serveur les 
nouvelles photos prises ? En sachant que j'en garde désormais une 
copie en local, mais qu'elles sont également envoyées sur Mapillary.


Cordialement,

Adrien P.



Le plus simple pour moi (et toi), c'est de relancer un takeout, qui ne 
prend en compte que les nouvelles photos sans tout recharger.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] sur-spécification ?

[Christian Quest]

Le 22/07/2020 à 14:15, osm.sanspourr...@spamgourmet.com a écrit :
Le 22/07/2020 à 11:31, Christian Quest - cqu...@openstreetmap.fr a 
écrit :

Et un petit "Rue Général De Gaulle" à remplacer en "Rue Général de
Gaulle" ;)


Corrigé aussi un Lann-Bihoué en Lann Bihoué car c'est un lieu-dit pas
une commune (j'avais avant homogénéisé dans le mauvais sens).

Merci.

Pour revenir au cas de la patte d'oie suivie d'une route à double-sens,
pour que ce soit utilisé par un moteur de navigation il faut
explicitement demander d'aller d'un côté à l'autre comme ceci :

https://www.openstreetmap.org/directions?engine=graphhopper_car=47.79607%2C-3.48274%3B47.79607%2C-3.48262#map=19/47.79592/-3.48270=D 



Par contre dans la pratique si tu es sorti sur la mauvaise sortie, le
temps que le navigateur s'en rende compte et propose un nouvel
itinéraire, tu seras déjà rendu après ce point de retournement théorique.

Sauf si tu t'appelles Stéphane avec un GPS de compète ;-) et que tu vas
lentement et encore : si tu es à vélo tu n'es pas sur cette patte. 



J'avais pas pensé à cet aspect et effectivement, à l'usage ça ne pose 
finalement pas de problème.


C'est donc plutôt du perfectionnisme... et il y a tellement d'autres 
choses à améliorer avant ça !


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] Nomi

[Martin Koppenhoefer]

sent from a phone

> On 22. Jul 2020, at 14:31, Francesco Ansanelli  wrote:
> 
> 
> Ciao Martin,
> 
> secondo te, "For disputed areas" sarebbero tutte le strade d'Italia o magari 
> vuol dire che se c'è un dubbio tra due nomi diversi vince quello indicato 
> sulla targa?



no, sono i punti 2 e 3 per le quali ho citato questo paragrafo


> Penso che l'uso dello stradario, coincida anche con l'uso del nome locale 
> (che si trova TIPICAMENTE sul cartello, come scritto nel wiki) e non vuol 
> dire prendi quello che c'è scritto e copialo pedissequamente, per quello c'è 
> il tag "inscription".


esatto, (inscription non lo userei in questo contesto). Se il caso fosse 
“atipico”, non sono da cancellare le alternative se hanno un loro perché...

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

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Gad Jo]

Merci Christian, je pensai que je devenait fou mais c'était un contributeur 
néerlandais qui a pris pour argent comptant la toponymie utilisée dans 
wikipedia.
Il aurait observé le nom des rues et des relations utilisé sur les rues il 
aurait eu un doute mais non... Il a fait ça un peu partout en France.
C'est vraiment qu'on est des handicapés du bocal pour avoir fait la même erreur 
partout dans le pays :-)

D'ailleurs est-il envisageable de remonter automatiquement ces erreurs de 
toponymie aux contributeur de wikipedia ou est-ce leur normes de nommage ? Si 
oui c'est dommage et complexifie la mutualisation de l'information.

Le July 22, 2020 9:23:47 AM UTC, Christian Quest  a 
écrit :
>Le 21/07/2020 à 20:32, Gad Jo a écrit :
>> Bonsoir,
>>
>> Suite à un changement sur quelques rues j'ai contacté le contributeur
>
>> comme quoi on met des tirets entre les mots généralement sur les 
>> villes ou après le mot saint(e)... C'est n'est pas exhaustif bien
>sûr.
>>
>> Suite à sa réponse il me met le doute quand il me renvoie vers 
>> l'orthographe utilisé sur wikipedia. J'aurai besoin d'information et 
>> par défaut je préfère toujours me dire que j'ai tort et vérifier
>avant 
>> de répondre
>>
>> La discutions est sur ce changeset 
>>
>https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232
>>
>> Quelle est la réponse approprié ?
>> -- 
>
>On n'ajoute pas de traits d'union dans les noms (sauf là où ils sont 
>normaux: Saint-Glinglin, Jean-Pierre, etc).
>
>Exception: la règle de toponymie pour les noms officiels des communes
>
>Là il y a des traits d'union partout, sauf après l'article initial:
>
>- Saint-Maur-des-Fossés
>
>- La Celle-Saint-Cloud
>
>
>Dans la zone du changeset je vois une "Rue Etienne-Gaillard", le trait 
>d'union ne devrait pas y figurer.
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>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

Re: [Talk-GB] Electric vehicle charging points

[Robert Whittaker (OSM lists)]

On Tue, 21 Jul 2020 at 23:12, Nick  wrote:
> Could the data be included in https://osm.mathmos.net/survey/ ?

I had a quick look at the National Charge Point Registry data a while
ago. I got as far as plotting a map showing both the OSM charge points
and those from the Registry:
https://osm.mathmos.net/chargepoint/progress/ . Unfortunately, the
Registry data seemed rather incomplete, and not always accurate. It
also wasn't clear exactly how to do matching between the two datasets.
I then got distracted by other things.

Due to the incompleteness of the Registry, there'd be no way to flag
OSM charge point objects that shouldn't be there. But if I could sort
out some way of matching between the two datasets, I would then be
able to add the charge points in the Registry that are "missing" in
OSM to https://osm.mathmos.net/survey/ .

-- 
Robert Whittaker

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

Re: [OSM-talk-fr] takeout Mapillary... 12To archivés

[PanierAvide]

Bonjour,

Merci pour ce point d'étape. Je ne dois pas être le seul à continuer à 
faire des photos depuis la nouvelle de rachat et la demande de takeout. 
Y a-t'il une façon de transmettre sur ce serveur les nouvelles photos 
prises ? En sachant que j'en garde désormais une copie en local, mais 
qu'elles sont également envoyées sur Mapillary.


Cordialement,

Adrien P.

Le 22/07/2020 à 11:48, Christian Quest a écrit :
Les photos Mapillary de notre zimmy national ont toute été 
archivées... 3.4To à lui tout seul pour 1.5M de photos.


J'en suis à 12To au total, encore 2.6To de dispo sur la grappe 
actuelle de disques.



Les dernières photos récupérées ne sont pas floutées. Pour faire 
tourner des algo d'IA, plusieurs pistes sont explorées, mais souvent 
gourmandes en ressources de calcul (et énergie), et ce même en 
utilisant un GPU à la place de CPU habituels.


La dernière piste identifiée... les EdgeTPU mis au point par Google. 
Ce sont des circuits dédiés (ASIC) qui permettent de faire tourner des 
algos basés sur des réseaux de neurones légers. Triple avantage: c'est 
rapide, peu consommateur d'énergie (2W) et pas cher (40€ pièce). J'en 
ai reçu deux lundi... à tester prochainement.


Infos ici: https://coral.ai/products/m2-accelerator-bm




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

Re: [Talk-it] Nomi

[Francesco Ansanelli]

Ciao Martin,

secondo te, "For disputed areas" sarebbero tutte le strade d'Italia o
magari vuol dire che se c'è un dubbio tra due nomi diversi vince quello
indicato sulla targa?
Penso che l'uso dello stradario, coincida anche con l'uso del nome locale
(che si trova TIPICAMENTE sul cartello, come scritto nel wiki) e non vuol
dire prendi quello che c'è scritto e copialo pedissequamente, per quello
c'è il tag "inscription".

Francesco
Il giorno mer 22 lug 2020 alle ore 14:01 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> non sono guidepost, e non c'è nemmeno un tag per "plaque" che non è
> commemorativo. Leggi il wiki:
> https://wiki.openstreetmap.org/wiki/Names
>
> The common default name. (Notes:
>
>- For disputed areas, please use the name as displayed on, e.g.,
>street signs for the name tag
>- Put all alternatives into either localized name tags (e.g.,
>name:tr/name:el) or the variants (e.g., loc_name/old_name/alt_name)
>- Do not abbreviate words: Abbreviation don't do it)
>
> https://wiki.openstreetmap.org/wiki/Key:name
>
> Note that OSM follows the On the Ground Rule
> . Names
> recorded in name=* tag are ones that are locally used, especially ones
> typically signposted.[1]
>  However, if
> the name on a signpost is abbreviated to save space and the name can be
> (and commonly is) spelled without an abbreviation, then don't abbreviate it
> in Openstreetmap.
> ...
>
> Ciao
> Martin
>
>
> PS: Questa pagina: https://wiki.openstreetmap.org/wiki/IT:Key:name
> che tra altro non sembra una traduzione della pagina inglese, riporta un
> esempio int_name=E64, ma penso dovrebbe essere int_ref.
>
>
>
> ___
> 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-GB] Surveying rural buildings

[Mateusz Konieczny via Talk-GB]

Jul 20, 2020, 12:29 by n...@foresters.org:

> Dear all
>
> I have been mapping a few properties using Bing maps with local knowledge 
> supplemented by some physical measuring (tape measure or simply pacing). I 
> now want to ramp up my mapping but the challenge especially in rural areas is 
> that sometimes the outline of a building is not clear - either obscured (e.g. 
> trees) or unclear (e.g. decking or car ports). Also some aerial imagery is 
> offset. Also, most of the properties are not along public roads. So my 
> question is what are the preferred methods for surveying that others are 
> using?
>
Nobody replied so far so...

I am not worried too much about geometry offset, especially in rural areas where
moving building to fix offset is usually not problematic.

> Supplementary question, do you include or exclude conservatories, car ports 
> etc. from the main structure of the property?
>
It depends. I usually include them in case of armchair mapping of aerial images 
(unless there is
a visible gap). In mapping during survey it depends whatever car port is part 
of a building structure
or a separate structure standing next to house.

> I guess at the back of my mind is what do people perceive as the purpose of 
> mapping (hope I have not opened a can of worms).
>
In my case I map what is useful for projects that I use/like or is very simple 
to map
(=available as StreetComplete quest).

So right now I map parking lanes for https://github.com/dabreegster/abstreet
and in rural areas I tend to map hiking routes rather than buildings.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] sur-spécification ?

[osm . sanspourriel]

Le 22/07/2020 à 11:31, Christian Quest - cqu...@openstreetmap.fr a écrit :

Et un petit "Rue Général De Gaulle" à remplacer en "Rue Général de
Gaulle" ;)


Corrigé aussi un Lann-Bihoué en Lann Bihoué car c'est un lieu-dit pas
une commune (j'avais avant homogénéisé dans le mauvais sens).

Merci.

Pour revenir au cas de la patte d'oie suivie d'une route à double-sens,
pour que ce soit utilisé par un moteur de navigation il faut
explicitement demander d'aller d'un côté à l'autre comme ceci :

https://www.openstreetmap.org/directions?engine=graphhopper_car=47.79607%2C-3.48274%3B47.79607%2C-3.48262#map=19/47.79592/-3.48270=D

Par contre dans la pratique si tu es sorti sur la mauvaise sortie, le
temps que le navigateur s'en rende compte et propose un nouvel
itinéraire, tu seras déjà rendu après ce point de retournement théorique.

Sauf si tu t'appelles Stéphane avec un GPS de compète ;-) et que tu vas
lentement et encore : si tu es à vélo tu n'es pas sur cette patte.

Jean-Yvon



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

[OSM-talk-fr] "Intégration des autoroutes" de la Guyane avec les pays voisins

[Adrien André via Talk-fr]

Bonjour,

j'ai été contacté pour donner mon avis sur
https://forum.openstreetmap.org/viewtopic.php?id=70063
c.-à-d. changement de highway=primary en trunk.

Le réseau routier c'est pas vraiment mon dada, il y a certainement des
personnes bien plus averties sur cette liste :)

Cela ressemble à une traduction approximative de "highway" mais, il n'y
a pas d'*autoroute* en Guyane.
Vraiment juste une *route nationale* (2x1 voie sans terre-plein central) :
https://openstreetcam.org/details/1299295/1494/track-info

L'apport du changement proposé n'est pas totalement clair pour moi.
Cela semble principalement basé sur la proposition "Highway key voting
importance" [1].
L'autre référence donnée [2] a l'air d'être motivée par le rendu.

À priori je pense que notre groupe local suivra ce qui est généralement
indiqué sur
https://wiki.openstreetmap.org/wiki/FR:Key:highway

[1]
https://wiki.openstreetmap.org/wiki/Proposed_features/Highway_key_voting_importance
[2]
https://wiki.openstreetmap.org/wiki/FR:Key:highway#Exceptions_aux_attributs_physiques

-- 
Adrien A.



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

Re: [Talk-it] Nomi

[Martin Koppenhoefer]

non sono guidepost, e non c'è nemmeno un tag per "plaque" che non è
commemorativo. Leggi il wiki:
https://wiki.openstreetmap.org/wiki/Names

The common default name. (Notes:

   - For disputed areas, please use the name as displayed on, e.g., street
   signs for the name tag
   - Put all alternatives into either localized name tags (e.g.,
   name:tr/name:el) or the variants (e.g., loc_name/old_name/alt_name)
   - Do not abbreviate words: Abbreviation don't do it)

https://wiki.openstreetmap.org/wiki/Key:name

Note that OSM follows the On the Ground Rule
. Names
recorded in name=* tag are ones that are locally used, especially ones
typically signposted.[1]
 However, if the
name on a signpost is abbreviated to save space and the name can be (and
commonly is) spelled without an abbreviation, then don't abbreviate it in
Openstreetmap.
...

Ciao
Martin


PS: Questa pagina: https://wiki.openstreetmap.org/wiki/IT:Key:name
che tra altro non sembra una traduzione della pagina inglese, riporta un
esempio int_name=E64, ma penso dovrebbe essere int_ref.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Trop de relation tue la relation, landuse=*, aide raccourci JOSM

[Philippe Verdy]

Au sujet des bornes de repérage de gazoduc (très visibles sur l'imagerie
aérienne comme de gros points jaunes):
http://smartsleep.e-monsite.com/pages/panneau-de-reperage-des-reseaux.html
Ces sont des poitns de repère géodésiques quasi parfaits, mieux repérables
et plus précis souvent que les lignes électriques. On devrait pouvoir
compléter tous les points de passage par ces bornes.
Sur certaines images on les voit de couleur verdâtre, mais leur couleur
normale est jaune (à l'état neuf) même si un peu de végétation s'est
développée dessus ou s'ils sont salis par des dépôts.
Cela devrait permettre de compléter le réseau mais il n'est pas connecté
partout (et ce n'est pas toujours facile de savoir quel est le point de
raccordement suivant quand il y a plusieurs conduites plus proches entre
elles que les distances entre ces bornes.
Normalement ce réseau devrait être complètement terminé sur des
installations de distribution, masi ce n'est pas le cas partout. On trouve
encore des segments qui aboutissent à rien, sans installation au bout.
Pourtant pour le calage ce serait parfait, mais les points utilisés (pour
relier les segments) n'ont aucun tag particulier, il en faudrait je pense
(même si on peut trouver ces points dans la géométrie des lignes de
gazoduc, je ne suis pas sûr que tous les points utilisés correspondent à
une borne posée, visible également de loin.

Il y a aussi des bornes similaires pour le réseau électrique enterré mais
de couleur rouge, moins facile à repérer pour moi sur l'imagerie.

(à moins que ce soit lié à ma "deutéranopie" légère qui me fait confondre
certains oranges et verts, proches du beige-ocre à cause d'une vision
décalée du pigment vert dont la bande centrale est décalée vers le jaune
donc plus proche du rouge, et légèrement sensible aussi au pigment rouge de
base: c'est courant mais contrairement à une croyance populaire sur le
"daltonisme", dont il existe de nombreuses variantes différentes, je ne
confonds pas toutes les couleurs et j'ai une vision trichromatique, mais
qui différencie moins de couleurs différentes dans la gamme du rouge au
vert mais au contraire plus de couleurs dans les verts au cyan; le
daltonisme complet est en fait très rare: absence quasi totale d'un ou deux
pigments, mais la deutéronopie la plus commune est la présence d'un pigment
juste un peu différent).


Le mer. 22 juil. 2020 à 12:56, Philippe Verdy  a écrit :

> Les imports de bâtiments du cadastre ne sont guère mieux, découpages
> inutiles, voire positions farfelues, géométrie aussi hasardeuse (et là je
> ne tiens pas compte des décalages qui peuvent s'expliquer par l'ancienne
> triangulation avant la conversion numérique et pas corrigés ensuite, ce qui
> est un travail de titan et qui coûte cher pour une petite commune rurale ou
> même pour sa communauté locale). Il faut dire que c'était du déclaratif à
> l'époque sur des plans approximatifs pas forcément validés par des
> géomètres experts, et repris tels quels à une époque ou la
> précision demandée n'était pas celle des moyens d'aujourd'hui: il n'y avait
> pas encore le satellite, le GPS, et d'aussi bonnes images aériennes (qui
> étaient longues et couteuses et pas demandées même aux géomètres experts du
> coin qui se basaient juste sur la triangulation existante et quelques
> outils de relvés moins précis qu'aujourd'hui.
>
> Globalement si la surface bâtie correponsdait à peu près (les écarts
> étaient mineurs du moment que c'était localisé dans les bonnes parcelles,
> que ces parcelles préexistantes (et redécoupées à différents époques)
> gardent leur proportion relative), les tracés étaient faits à la main en
> surchargenant les planches existantes sans les refaire et ça passait pour
> toutes les constructions individuelles, tant qu'aucun litige n'apparaissait
> entre les occupants ou voisins et ne se réglait devant un tribunal ou par
> le passage d'un géomètre pour constater sur place et revoir si le balisage
> semblait intact et pas déplacé subrepticement dans un passé assez court
> (après, impossible de savoir où était l'ancienne balise). C'était d'autant
> plus vrai quand nombre de routes étaient des chemins de terre qui se
> "déplaçaient" au gré des saisons, en rabotant certains fossés au besoin du
> côté approprié et en abattant certains arbres qui auraient permis de le
> détecter. Bien des choses se passaient hors de tout signalement au cadastre
> et ça passait inaperçu car les anciens plans métrés étaient perdus. Ensuite
> il ya eu les périodes de guerre qui ont chamboulé le paysage et permis des
> reconstructions "sauvages" sans aucun permis de construire, mais acceptés
> tels quels en l'état après et aucune autoisation n'était nécessaire pour
> démolir un vieux batiment afin d'en construire un équivalent à coté ou une
> dépendance attenante, devenue ensuite le corps principal quand l'ancien
> bâtiment hors d'âge (pas toujours en pierre mais en matériaux récupérable
> ou recyclable pour faire autre chose) était mis à terre.
>
> Si 

Re: [OSM-talk-fr] Trop de relation tue la relation, landuse=farmyard, aide raccourci JOSM

[Vincent Bergeot]

Le 22/07/2020 à 11:13, Christian Quest a écrit :

Le 21/07/2020 à 19:06, Vincent Bergeot a écrit :


Le wiki ne parle pas de relation,

dans l'infobox la relation est barrée, ce que j’interprète comme 
déconseillé




Ce n'est pas un tag pour une relation en soit (sémantique), MAIS... 
cela peut s'appliquer si besoin à une relation type=multipolygon 
(géométrique)



ok,



[]







*Culture OSM*

Il y en a 25000 quand même selon taginfo, cela veut dire que cela a 
été à la mode à un moment ?



25000 quoi ?

relation avec le tag landuse=farmyard 
https://taginfo.openstreetmap.org/tags/landuse=farmyard


et donc pour ma culture osm, je me demandais si il y avait eu une 
mode, une raison, une explication à cela !


merci pour vos retours

ça fait beaucoup en effet, pas impossible que ça provienne d'imports 
type CLC... et on en a seulement 5 en France 
https://taginfo.openstreetmap.fr/tags/?key=landuse=farmyard#overview


il y a un bug du coté de taginfo je pense, juste sur le sud-ouest il y 
en a une 50aine http://overpass-turbo.eu/s/WkJ


cela confirme que les données taginfo.openstreetmap.fr sont "fausses 
mais homogènes" 
(https://github.com/osm-fr/infrastructure/issues/214#issuecomment-660840170



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Trop de relation tue la relation, landuse=*, aide raccourci JOSM

[Philippe Verdy]

Les imports de bâtiments du cadastre ne sont guère mieux, découpages
inutiles, voire positions farfelues, géométrie aussi hasardeuse (et là je
ne tiens pas compte des décalages qui peuvent s'expliquer par l'ancienne
triangulation avant la conversion numérique et pas corrigés ensuite, ce qui
est un travail de titan et qui coûte cher pour une petite commune rurale ou
même pour sa communauté locale). Il faut dire que c'était du déclaratif à
l'époque sur des plans approximatifs pas forcément validés par des
géomètres experts, et repris tels quels à une époque ou la
précision demandée n'était pas celle des moyens d'aujourd'hui: il n'y avait
pas encore le satellite, le GPS, et d'aussi bonnes images aériennes (qui
étaient longues et couteuses et pas demandées même aux géomètres experts du
coin qui se basaient juste sur la triangulation existante et quelques
outils de relvés moins précis qu'aujourd'hui.

Globalement si la surface bâtie correponsdait à peu près (les écarts
étaient mineurs du moment que c'était localisé dans les bonnes parcelles,
que ces parcelles préexistantes (et redécoupées à différents époques)
gardent leur proportion relative), les tracés étaient faits à la main en
surchargenant les planches existantes sans les refaire et ça passait pour
toutes les constructions individuelles, tant qu'aucun litige n'apparaissait
entre les occupants ou voisins et ne se réglait devant un tribunal ou par
le passage d'un géomètre pour constater sur place et revoir si le balisage
semblait intact et pas déplacé subrepticement dans un passé assez court
(après, impossible de savoir où était l'ancienne balise). C'était d'autant
plus vrai quand nombre de routes étaient des chemins de terre qui se
"déplaçaient" au gré des saisons, en rabotant certains fossés au besoin du
côté approprié et en abattant certains arbres qui auraient permis de le
détecter. Bien des choses se passaient hors de tout signalement au cadastre
et ça passait inaperçu car les anciens plans métrés étaient perdus. Ensuite
il ya eu les périodes de guerre qui ont chamboulé le paysage et permis des
reconstructions "sauvages" sans aucun permis de construire, mais acceptés
tels quels en l'état après et aucune autoisation n'était nécessaire pour
démolir un vieux batiment afin d'en construire un équivalent à coté ou une
dépendance attenante, devenue ensuite le corps principal quand l'ancien
bâtiment hors d'âge (pas toujours en pierre mais en matériaux récupérable
ou recyclable pour faire autre chose) était mis à terre.

Si on regarde le cadastre concernant les constructions agricoles "légères",
il y en a pas mal qui ne correspondent plus à rien, et même les résidences
actuelles rénovées oublient des aménagements ou leur fermeture complète
alors que c'était déclaré "sans mur". En milieu très rural, c'est monnaie
courante, même si aujourd'hui les procédures sont plus pointilleuses (mais
pas appliquées par les communes elles-mêmes, elle font supporter le
coût par les demandeurs de permis de construire/démolir/lotir/modifier en
demandant de recourir à des experts agréés). aujourd'hui ces mêmes experts
ne peuvent ignorer l'imagerie aérienne et ne prendraient plus le risque de
s'appuyer juste sur les anciens métrages du cadastre. Mais qui met à jour
ensuite le cadastre même si de nouveaux plans plus précis apparaissent (les
communes n'en ont plus les moyens)?

On peut se demander alors à quoi sert encore aujourd'hui le cadastre et si
sa mise à jour ne générerait pas davantage de coûts juridiques et des
problèmes politiques locaux avec les administrés électeurs ou parfois
décideurs même au sein des petites communes où il y a de moins en moins de
candidats aux conseils municipaux et de moins en moins d'audience dans les
assemblées publiques, sachant que nombre de décisions ne se font plus non
plus à l'échelle de la commune.

Pourtant légalement le cadastre fait encore foi, de façon limitée, juste
pour savoir qui possède quoi et à peu près combien.; le reste des litiges
ce sont des litiges "privés" de voisinage pour quelques arbres ou un pan de
mur mitoyen ou un droit de passage sur un chemin non communal, voire un
ancien chemin communal rendu inutilisable et inacessible par le voisinage,
et d'autres qui n'ont plus lieu d'être depuis le remembrement agricoles
massif des années 1960 et 1970: les chemins ont disparu, des tas de
ruisseaux aussi, remplacés par des drains enterrés.

Encore aujourd'hui des lignées d'arbres, haies et fossés disparaissent pour
agrandir les surfaces de monoculture. Il reste alors peu de repères fiables
et précis, hormis les lignes électriques ou téléphoniques non enterrées (si
leurs opérateurs ont mis à jour leurs bases géographiques qui devraient
être publiques) et les quelques gazoducs enterrés et marqués précisément en
surface par les gros points de repère jaune (très visibles sur l'imagerie
et généralement en limite de parcelle au bord d'un chemin public qu'il
traverse sous leur fossé): ces points sont maintenant plus nombreux que les

Re: [Talk-us] Labeling forestry service roads/tracks

[tj-osmwiki]

Thanks, that sounds very sensible. I'll use it in lieu of any better
suggestions.


Mark.

On 2020/07/21 7:48, Mike Thompson wrote:
>
>
> On Mon, Jul 20, 2020 at 4:46 AM  > wrote:
>
> Mike,
>
> Good idea on the route references. What should the network be set to?
>
> Others on this list are better able to answer that question, but my
> opinion is network=US:FS: the end>
>
> ___
> 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: [OSM-talk-fr] takeout Mapillary... 12To archivés

[Christian Quest]

Les photos Mapillary de notre zimmy national ont toute été archivées... 
3.4To à lui tout seul pour 1.5M de photos.


J'en suis à 12To au total, encore 2.6To de dispo sur la grappe actuelle 
de disques.



Les dernières photos récupérées ne sont pas floutées. Pour faire tourner 
des algo d'IA, plusieurs pistes sont explorées, mais souvent gourmandes 
en ressources de calcul (et énergie), et ce même en utilisant un GPU à 
la place de CPU habituels.


La dernière piste identifiée... les EdgeTPU mis au point par Google. Ce 
sont des circuits dédiés (ASIC) qui permettent de faire tourner des 
algos basés sur des réseaux de neurones légers. Triple avantage: c'est 
rapide, peu consommateur d'énergie (2W) et pas cher (40€ pièce). J'en ai 
reçu deux lundi... à tester prochainement.


Infos ici: https://coral.ai/products/m2-accelerator-bm


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-GB] Electric vehicle charging points

[Tony OSM]

I have compared some of the data in my locale against several I have mapped.

The NCR data does not indicate - I think - the number of chargepoints at 
a location - my Local Asda has 4 but only one entry in NCR. Others are 
missing and some recent ones (in the last year) included. One at my 
local Nissan dealer is not included.


_Could the data be included in _https://osm.mathmos.net/survey/_?_

Be great if it was._
_

_Tony
_

On 21/07/2020 23:11, Nick wrote:


Could the data be included in https://osm.mathmos.net/survey/ ?

On 21/07/2020 22:42, Colin Smale wrote:


On 2020-07-21 22:54, Mark Goodge wrote:

It's the errors which are more of a problem, because it's generally 
better not to map something than to map it wrongly.


This is a difficult point. Data is never 100% complete, and 
frequently not 100% accurate. At what point it becomes better not to 
have the thing in OSM at all, is rather subjective.

If the location was only accurate to ±50m, would it still be good enough?
If the operator was not tagged, would it still be good enough?
Is an "imperfect" object in OSM more likely to get corrected than a 
missing object is to get added? Should I not add a missing object 
because I cannot be sure of the "operator" for example? Talking about 
the charging points data set, how can one detect what is an error?
I would say, get the data out there, and let the world feed back any 
inaccuracies to the source for inclusion in the next version.


___
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: [OSM-talk-fr] sur-spécification ?

[Christian Quest]

Le 22/07/2020 à 00:12, osm.sanspourr...@spamgourmet.com a écrit :

Je vois des interdiction de faire demi-tour sur une départementale en
sortie de rond-point :

https://www.openstreetmap.org/relation/11332801#map=19/47.78898/-3.47998

Stricto sensu ce n'est pas faux mais est-ce que ça a le moindre intérêt ? 



Il y a sûrement une ligne continue (pas visible vu que c'est un nouveau 
rond-point qui n'est pas visible sur l'ortho), donc c'est pas faux du tout.


J'hésite à ajouter ce genre de restrictions en espérant que les 
calculateurs d'itinéraires prennent en compte la géométrie, mais il 
serait effectivement normal de l'expliciter pour lever toute ambiguïté.


Par contre, celle ci est inutile: 
https://www.openstreetmap.org/relation/11332800


Le junction=roundabout indique qu'on ne peut pas repartir à contre-sens 
vers la gauche.



Et un petit "Rue Général De Gaulle" à remplacer en "Rue Général de 
Gaulle" ;)



--
Christian Quest - OpenStreetMap France


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

Re: [Talk-us] Labeling forestry service roads/tracks

[tj-osmwiki]

Thanks Tod.

Mark.

On 2020/07/21 8:58, Tod Fitch wrote:
>
>> On Jul 20, 2020, at 4:48 PM, Tod Fitch > > wrote:
>>
>>
>>> On Jul 20, 2020, at 4:35 PM, Clifford Snow >> > wrote:
>>>
>>> On Mon, Jul 20, 2020 at 3:46 AM >> > wrote:
>>>
>>> Clifford,
>>>
>>> Could you repost the legend? It's hard/impossible to make out the
>>> surface reliably from aerial photos.
>>>
>>>
>>> Sure - here is a
>>> link https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S 
>>
>> Looks a bit different than the legend on my April 2020, Coconino
>> National Forest Travel Map:
>>
>> https://cloud.fitchfamily.org/index.php/s/eKCYzc4TfjMMfdN
>>
>> —Tod
>
> Oops. Deleted it off my cloud after sending email. Here is it
> again: https://cloud.fitchfamily.org/index.php/s/9nrCyifxX2swSH8
>
> Just looked at a map for the Los Padres and for the Sabino Canyon
> Recreational area in the Santa Catalina Mountains of the Coronado NF.
> Those legends are different yet.
>
>   * Is there a national standard that these forests are ignoring?
>   * Is it on a FS region basis?
>   * Is it on a forest basis?
>   * Does it vary based on when a map was published?
>
> I don’t see a consistent pattern with the FS maps I have at hand.
>
> —Tod
>
>
> ___
> 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-us] Labeling forestry service roads/tracks

[tj-osmwiki]

Thanks Clifford.

Mark.


On 2020/07/21 10:08, Clifford Snow wrote:
> The legend is just for the USFS road layer that is served by Mapbox on
> JOSM.
>
>
> Sent from my Android phone.
>
> On Mon, Jul 20, 2020, 4:48 PM Tod Fitch  > wrote:
>
>
>> On Jul 20, 2020, at 4:35 PM, Clifford Snow
>> mailto:cliff...@snowandsnow.us>> wrote:
>>
>> On Mon, Jul 20, 2020 at 3:46 AM > > wrote:
>>
>> Clifford,
>>
>> Could you repost the legend? It's hard/impossible to make out the
>> surface reliably from aerial photos.
>>
>>
>> Sure - here is a
>> link https://mycloud.snowandsnow.us/index.php/s/7zQNGbyNQqBMj2S 
>
> Looks a bit different than the legend on my April 2020, Coconino
> National Forest Travel Map:
>
> https://cloud.fitchfamily.org/index.php/s/eKCYzc4TfjMMfdN
>
> —Tod
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Question sur la règle de nommage des rues

[Christian Quest]

Le 21/07/2020 à 20:32, Gad Jo a écrit :

Bonsoir,

Suite à un changement sur quelques rues j'ai contacté le contributeur 
comme quoi on met des tirets entre les mots généralement sur les 
villes ou après le mot saint(e)... C'est n'est pas exhaustif bien sûr.


Suite à sa réponse il me met le doute quand il me renvoie vers 
l'orthographe utilisé sur wikipedia. J'aurai besoin d'information et 
par défaut je préfère toujours me dire que j'ai tort et vérifier avant 
de répondre


La discutions est sur ce changeset 
https://www.openstreetmap.org/changeset/88176811#map=15/43.1820/3.0232


Quelle est la réponse approprié ?
--


On n'ajoute pas de traits d'union dans les noms (sauf là où ils sont 
normaux: Saint-Glinglin, Jean-Pierre, etc).


Exception: la règle de toponymie pour les noms officiels des communes

Là il y a des traits d'union partout, sauf après l'article initial:

- Saint-Maur-des-Fossés

- La Celle-Saint-Cloud


Dans la zone du changeset je vois une "Rue Etienne-Gaillard", le trait 
d'union ne devrait pas y figurer.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Trop de relation tue la relation, landuse=farmyard, aide raccourci JOSM

[Christian Quest]

Le 21/07/2020 à 19:06, Vincent Bergeot a écrit :


Le wiki ne parle pas de relation,

dans l'infobox la relation est barrée, ce que j’interprète comme 
déconseillé




Ce n'est pas un tag pour une relation en soit (sémantique), MAIS... cela 
peut s'appliquer si besoin à une relation type=multipolygon (géométrique)


Je ne vois pas trop les cas où ça serait vraiment adapté... à part 
éventuellement une grande emprise de ferme qui engloberait une zone 
résidentielle.






*JOSM*

Je ne trouve pas avec JOSM le raccourci de la mort qui tue pour 
supprimer la relation en collant les attributs sur le outer ? à quel 
endroit ai-je mal cherché ? Cela n'existe pas ?




Pas à ma connaissance, comme Georges l'a indiqué, le plus simple semble:

- double clic à l'intérieur du multipolygone, cela va charger les 
attributs


- suppression de la relation

- clic sur le polygone englobant

- Shirt-R pour recopier les tags

- retirer le tag type=multipolygon

Et oui, 5 manips... qui dit mieux ? ;)



Pas mieux non

Bien sûr, cela n'est ok que si le outer est un unique polygone (c'était 
le cas sur ton exemple).






*Culture OSM*

Il y en a 25000 quand même selon taginfo, cela veut dire que cela a 
été à la mode à un moment ?



25000 quoi ?

relation avec le tag landuse=farmyard 
https://taginfo.openstreetmap.org/tags/landuse=farmyard


et donc pour ma culture osm, je me demandais si il y avait eu une 
mode, une raison, une explication à cela !


merci pour vos retours

ça fait beaucoup en effet, pas impossible que ça provienne d'imports 
type CLC... et on en a seulement 5 en France 
https://taginfo.openstreetmap.fr/tags/?key=landuse=farmyard#overview



--
Christian Quest - OpenStreetMap France

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

Re: [Talk-it] Nomi

[Francesco Ansanelli]

Il mer 22 lug 2020, 09:08 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> > On 22. Jul 2020, at 07:05, Francesco Ansanelli 
> wrote:
> >
> > Sono davvero così importanti le targhe fatte dai comuni?
>
>
> sì, sono la cosa più rilevante per chi usa la mappa per orientarsi.
>

Caricale come plaque e guidepost...

>
>
> 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

Re: [Talk-it] Nomi

[Martin Koppenhoefer]

sent from a phone

> On 22. Jul 2020, at 07:05, Francesco Ansanelli  wrote:
> 
> vuoi metterli così nel tag name?
> Inoltre, spezzi la strada e cambi tutti i numeri civici?


no. Maiuscole e minuscole metterei standardizzati. Non spezzerei nemmeno la 
via, le due ortografie possono tranquillamente convivere (alt_name ecc). Per me 
possiamo fare un eccezione per ISTAT, e aggiungere un istat_name se questo 
fosse utile a qualcuno (tipo confronto con altre liste), ma non è il “name” se 
non si trova in loco e non è nemmeno ufficiale (perché non deliberato dal 
consiglio comunale), ma soltanto un dolce sogno come “dovrebbe essere” ;-)

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

Re: [Talk-GB] Electric vehicle charging points

[Jez Nicholson]

Collating and conflating is one thing, but we really need to encourage
custom data apps like https://www.zap-map.com/ to use OSM as an active
database which they feed back to. This will only happen when private
companies realise that long term value is not in the data itself (because
other people can collect it too) but in the extra deep knowledge gained in
curating it, and from services on top of the raw data.


On Tue, 21 Jul 2020, 23:12 Nick,  wrote:

> Could the data be included in https://osm.mathmos.net/survey/ ?
> On 21/07/2020 22:42, Colin Smale wrote:
>
> On 2020-07-21 22:54, Mark Goodge wrote:
>
> It's the errors which are more of a problem, because it's generally better
> not to map something than to map it wrongly.
>
> This is a difficult point. Data is never 100% complete, and frequently not
> 100% accurate. At what point it becomes better not to have the thing in OSM
> at all, is rather subjective.
>
> If the location was only accurate to ±50m, would it still be good enough?
> If the operator was not tagged, would it still be good enough?
>
> Is an "imperfect" object in OSM more likely to get corrected than a
> missing object is to get added? Should I not add a missing object because I
> cannot be sure of the "operator" for example? Talking about the charging
> points data set, how can one detect what is an error?
>
> I would say, get the data out there, and let the world feed back any
> inaccuracies to the source for inclusion in the next version.
>
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://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-it] Nomi

[Martin Koppenhoefer]

sent from a phone

> On 22. Jul 2020, at 07:05, Francesco Ansanelli  wrote:
> 
> Sono davvero così importanti le targhe fatte dai comuni?


sì, sono la cosa più rilevante per chi usa la mappa per orientarsi. 


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