Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Philippe Verdy]

OK mais dans ce cas ça doit être dans un endroit accessible au public.

Mais si c'est une copropriété, celui qui autorise d'utiliser sa borne n'est
peut-être pas en droit de le faire avec sa copropriété qui limite le droit
des visiteurs et l'usage. Je me méfierais du cas d'une borne en bas d'une
cour d'immeuble sur un parking privé (réservé normalement aux résidents
selon le règlement de copropriété, y compris les immeubles HLM).

Si la borne n'est pas clairement indiquée et affichée comme accessible,
avec un responsable clairement désigné et au vu et su de sa copropriété (et
de l'autorité publique et autres voisins concernant les accès), je ne
mettrais rien du tout dans OSM.

Même si c'est un accord privé et que le résident est en droit de le donner,
ce n'est pas un engagement permanent pour n'importe qui, il peut le refuser
à loisir (par exemple parce qu'il réserve sa place pour quelqu'un d'autre
qu'il attend y compris dans son propre foyer). Le propriétaire devrait donc
être présent à chaque fois pour donner son accord ou pas. C'est lui qui
éventuellement mettra une annonce sur un site de partage et qui la retirera
à tout moment.

Donc, pas assez stable et fiable pour figurer dans OSM. On ne va pas taguer
les accords privés de gré à gré alors qu'il n'y a aucune garantie de
disponibilité et de continuité du service, ni de fiabilité du dispositif,
avec un entretien correct et une couverture suffisante en cas de dommages
subis (par exemple un court-circuit, un incendie de voiture par surchauffe
de batterie ou un accident des utilisateurs pour faille de sécurité comme
un défaut d'isolation ou de l'humidité sur les prises et des câbles sales
enduits de résidus conducteurs, ou un défaut des coupe-circuits et fusibles
de sécurité trafiqués par le propriétaire qui n'a pas voulu faire une
réparation correcte et connaissait les défauts en prenant les risques pour
lui-même mais omettra de les indiquer à l'utilisateur sur la façon la plus
sûre, d'utiliser l'équipement, selon le propriétaire qui peut ne pas être
très clair non plus dans ses explications et qui n'est pas non plus un
formateur).

D'ailleurs c'est comme pour l'autopartage avec des inconnus : on ne sait
pas si c'est sûr et on peut se méfier. Au risque sinon de cramer son
véhicule, ou d'un accident personnel, et ensuite la galère pour une faible
indemnisation (si on est encore vivant après l'accident).

Même Uber est poursuivi en justice pour le comportement de "ses"
conducteurs "autoentrepreneurs", parfois sans permis de conduire valide et
sans assurance. Blablacar au moins propose systématiquement aux clients une
garantie de couverture par une assurance pour les clients et prend à sa
charge les défauts des conducteurs qu'il contrôle de plus en plus et
responsabilise.

Si les véhicules électriques se développent, Blablacar (certainement aussi
Uber ou les réseaux de transport des collectivités) seront là pour proposer
aussi une offre de recharge en partage mais pas dans n'importe quelle
condition, ce sera contractualisé et couvert par des assurances incluses
dans le prix proposé et les marges de l'intermédiaire. Et parmi les points
de service proposés, on aura aussi des professionnels (hypermarchés,
stations-services, etc.) annonçant aussi la disponibilité de leurs bornes
via certains réseaux qu'ils ont choisi.

Et puis les bornes de recharge sont une des solutions possibles: en Israel
pas besoin de recharger, des stations-services automatisées changent en une
minute la batterie standardisée, située sous le véhicule et consignée,
aussi vite qu'on fait le plein de carburant avec une carte bancaire. La
station s'occupe alors de la recharge et l'entretien des batteries en
réserve, leur remplacement et leur recyclage.


Le sam. 18 janv. 2020 à 23:23, marc marc  a
écrit :

> Le 18.01.20 à 19:03, Philippe Verdy a écrit :
> > Le cas "private" ne devrait pas exister pour les stations de recharge
>
> réponse d'un gars qui en ajoute :
> un jour je passes devant un immeuble, il y une borne, je l'ajoutes dans
> osm.
> la fois d'après que t'y vas, tu vas en avance pour noter les détails
> (opérateur, prise, ...) et là t'apprends que c'est d'accès privé.
> supprimer la borne d'osm serait une erreur parce que le prochain va
> refaire la même recherche une 2ieme fois.
> alors access=private a tous son sens... surtout que la prochaine fois
> j'irai discuter avec le gars voir s'il n'a pas envie de la rendre dispo
> à la demande comme un autre l'a fait avant lui.
> ouais le collaboratif, c'est pas que osm.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Conciergerie ?

[Philippe Verdy]

Le sam. 18 janv. 2020 à 23:23, marc marc  a
écrit :

> Le 18.01.20 à 19:30, Cédric Frayssinet via Talk-fr a écrit :
> > chaîne de conciergerie technique : http://lesjules.com/
>
> office=company
>

C'est très vague... Il faudrait réfléchir à la situation des cas de plus en
plus fréquent des sociétés et commerces multiservices. Ici un "B2C" aurait
été peut-être plus précis. Ca reste un commerce au sens que cela vise
surtout les particuliers (mais pas que) vu que ce sont de petits dépannages.

Il s'agit surtout de servir d'intermédiaire entre des professionnels
qualifiés (employés par eux ou des artisans délégués, dont de plus en plus
nombreux "auto-entrepreneurs", entreprises à un seul salarié que les
intermédiaires ne veulent plus employer directement avec des contrats de
travail de longue durée... quoique Uber et d'autres sociétés ont été
condamné à requalifier les multiples contrats de service ou CDD sur une
longue période en contrats de travail CDI, y compris les simples femmes de
ménage employées à l'heure avec seulement des chèques-emplois.

Cependant la loi va vers plus de "flexibilité" et les contraintes légales
se relâchent même si ensuite les tribunaux ont à gérer des abus répétés de
ces contrats courts et l'absence de couverture sociale ou de couverture en
cas de maladie, entièrement à la charge de l'auto-entrepreneur qui
n'arrivent pas avec leurs contrats courts à souscrire à une mutuelle, ou à
bénéficier des indemnités-chômage avec trop de périodes de carence dans les
intercontrats, et pas de compensation suffisante dans ces contrats courts
et justifier de trimestres donnant droit à la retraite.

La tentative de réforme précipitée en cours complique encore les choses, le
calcul par trimestre étant de plus en plus contestable et les régimes ne
couvrant pas bien les autoentrepreneurs à qui on ne donne pas le choix que
ce statut, de même pour nombre de retraités obligés de se déclarer comme
employeur à l'URSAFF pour avoir des aides sociales qui ne leur sont plus
versées directement pour permettre l'emploi avec des chèques-service, et
obligés de faire appel à une comptatiblité externe coûteuse puisqu'ils ne
sont pas formés à être chefs d'entreprise ou n'ont même plus la possibilité
de le faire en cas de dépendance).

Alors ces sociétés intermédiaires sont une solution possible utile aux
particuliers qui seront trop embêtés avec les histoires compliquées de
gestion administrative... à condition que ces sociétés emploient
correctement leurs artisans avant de proposer ces services aux particuliers.

Le commerce est en pleine révolution, tout change maintenant très vite avec
la vente en ligne et ça se voit dans nos villes et toutes les enseignes de
moins en moins spécialisées, de plus en plus virtualisées avec juste
quelques services locaux limités mais plus pour la vente elle-même. On ne
sait plus vraiment ce qui achète, on connait de moins en moins les
professionnels qualifiés, les intermédiaires sont partout et prennent le
terrain sur les artisans. Il est compliqué de savoir à qui on parle, on a
de plus en plus de contact avec des robots ou des centres d'appel
délocalisés enracinés sur leurs procédure et qui ne savent pas répondre aux
demandes sortant un peu du cadre théorique.

Mais la loi a du retard à gérer ces situations, difficiles donc à décrire,
et nos villes changent complètement avec des boutiques vides et plus
d'interlocuteur fiable en charge d'un client pour un même contrat de
service. On ne connait plus son banquier, ou il faut contacter quelqu'un
dans une autre région si on arrive à le trouver. Les délais de règlement de
litiges s'allongent aussi. Le commerce en ligne n'apporte plus d'économie
réelle pour les clients, les prix sont trafiqués, les éléments de
comparaison aussi, l'information sur les produits ou services couverts est
de plus en plus difficile à lire, les contrats de service pullulent de
lignes d'exclusion en termes très vagues et souvent traitées de façon large
voire abusive par les intermédiaires qui inventent de nouveaux termes pour
ne pas donner d'engagements clairs et opposables.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] Update bus stop names

[jc...@mail.com]

On 18 January 2020 at 1340, Cj Malone wrote:
> Although now I have another issue, which data source should be preferred.

Whichever is the most up-to-date in your area. NaPTAN data has a 
ModificationDateTime field which shows when it was last updated. The SV data 
doesn't have such info so you'd need local knowledge about that. IoW bus stops 
seem to be branded which I think is rather unusual, so does the bus operator 
pay for updating them? That might be a clue to which is more recent.

Neil's example in Bristol shows that the paper timetable board has a newer name 
than both the metal sign and NaPTAN.

Conversely, in my area when many names/local_refs were changed three years ago, 
metal signs were changed first but the bus operators still used the old bus 
stop names until last year, and NaPTAN is a confusing mixture of old and new.

All local authorities are different!

Jez C

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

Re: [talk-au] Maxar bushfire imagery

[Andrew Harvey]

It's probably easier to use the mosaic at
https://github.com/osmlab/editor-layer-index/issues/763#issuecomment-575933772

On Sun, 19 Jan 2020 at 14:13, Andrew Harvey 
wrote:

> That's right it only shows up where the imagery covers, it's not a mosaic.
> See the index at
> https://gist.github.com/andrewharvey/57da8ad7f9f425d4c811e6cd33b2fdcb#file-index-geojson
>  click
> on the polygons and it shows the ID which you can use to find the right
> URL. I'm still working on making this easier.
>
> On Sun, 19 Jan 2020 at 11:11, Graeme Fitzpatrick 
> wrote:
>
>>
>>
>> On Sun, 19 Jan 2020 at 09:43, Andrew Harvey 
>> wrote:
>>
>>> You can take one of the URLs from above, but without the "tms:" at the
>>> start eg.
>>>
>>> https://{switch:a,b,c,d}.
>>> tiles.mapbox.com/v4/openstreetmapau.10300100921A2B00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
>>> 
>>>
>>> and in iD under the list of background layers at the bottom you should
>>> see "Custom", click the "..." and paste in the URL.
>>>
>>
>> Thanks, Andrew.
>>
>> That's what I thought & tried, but the map in iD doesn't move from where
>> I started & just stays dark?
>>
>> I'm guessing that you have to be already looking at the correct area to
>> start using this imagery?
>>
>> Is there any way of finding / working out just whereabouts ^ refers to?
>>
>>   Thanks
>>
>> Graeme
>>
>>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Maxar bushfire imagery

[Andrew Harvey]

That's right it only shows up where the imagery covers, it's not a mosaic.
See the index at
https://gist.github.com/andrewharvey/57da8ad7f9f425d4c811e6cd33b2fdcb#file-index-geojson
click
on the polygons and it shows the ID which you can use to find the right
URL. I'm still working on making this easier.

On Sun, 19 Jan 2020 at 11:11, Graeme Fitzpatrick 
wrote:

>
>
> On Sun, 19 Jan 2020 at 09:43, Andrew Harvey 
> wrote:
>
>> You can take one of the URLs from above, but without the "tms:" at the
>> start eg.
>>
>> https://{switch:a,b,c,d}.
>> tiles.mapbox.com/v4/openstreetmapau.10300100921A2B00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
>> 
>>
>> and in iD under the list of background layers at the bottom you should
>> see "Custom", click the "..." and paste in the URL.
>>
>
> Thanks, Andrew.
>
> That's what I thought & tried, but the map in iD doesn't move from where I
> started & just stays dark?
>
> I'm guessing that you have to be already looking at the correct area to
> start using this imagery?
>
> Is there any way of finding / working out just whereabouts ^ refers to?
>
>   Thanks
>
> Graeme
>
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Sounds very reasonable to me.

Thanks John

On Sat, 18 Jan 2020 at 20:02, Nate Wessel  wrote:

> In short, yes. But we should give them a clear option and a clear path
> toward doing it either way - written procedures, provide preprocessing
> scripts/help, etc.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-18 7:37 p.m., john whelan wrote:
>
> > But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> My interpretation is you're happy to leave this call to the local
> coordinator?  If they have no buildings it's fairly simple if there are
> buildings already mapped it becomes more complex.
>
> Thanks John
>
> On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:
>
>> Hi all,
>>
>> Daniel, thanks for continuing to prod the conversation along :-)
>>
>> I guess the point of disagreement here is that I generally don't agree
>> that the ODB buildings are of higher quality than what's already in OSM.
>> The ODB data I've seen is quite messy, and IMO only marginally better than
>> having no data in an area, especially if not properly checked and conflated
>> with surrounding OSM data. People seem to generally disagree with that
>> perspective though, so I'll assume that other areas are better represented
>> by their respective ODB data sources. Central Toronto may just not have
>> been well mapped by the City's GIS dept; it certainly isn't the easiest
>> thing to get right.
>>
>> My real worry here is that someone will be carelessly going through an
>> import replacing geometries and will destroy the work of an editor like
>> myself who carefully contributed their time to make a neat and accurate
>> map. I know for certain I've contributed better data in Toronto than what's
>> available from government sources for the same area.
>>
>> We must recall that governments produce building footprints in the same
>> way that we do - usually by tracing imagery, and there is little reason to
>> suppose that their data is better or more accurate just because it comes
>> from a seemingly authoritative source. It comes from interns - likely
>> interns with outdated software and low-resolution surveys.
>>
>> All that being said, I think my real reluctance to go with the flow here
>> stems from the haste and carelessness of the original importers in the GTA.
>> We're working toward a process that should be very different from theirs
>> though and I probably need to just trust that our process will be calmer,
>> slower, and more thoughtful. If it is, I can get on board.
>>
>> But also - sorry this is such a long email - we certainly should not be
>> manually doing re-conflation where buildings are very dense (e.g. downtown
>> Toronto) or where they have already been imported extensively (much of the
>> rest of the GTA). The import plan I'm working on for Toronto will take care
>> of most of this automatically by importing only in the sparse gaps between
>> existing OSM buildings. For other parts of Canada, this may not be much of
>> an issue at all - I wouldn't know.
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com 
>> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>>
>> Bonjour groupe,
>>
>> Here is a sequential summary of the last exchanges. I inserted some
>> comments […] within these exchanges description and summarize what I
>> understand from it at the end.
>>
>> *Nate* asked not to confuse the process of importing new data with that
>> of updating/modifying existing OSM data in order to keep things simple for
>> this import.
>>
>> *Daniel* (I) responded that importing new data and updating/modifying
>> existing ones at the same time (when necessary) is not unusual in OSM [*and
>> would be more efficient*].
>>
>> *John* replied that importing new data and updating/modify existing data
>> when required worked quite nicely when importing Ottawa.
>>
>> *Nate *explained he believes that the buildings will not be compared
>> manually since there are hundreds of thousands of them in OSM for Toronto
>> alone. In other words, he thinks there will be automated edits, and these
>> edits are not governed by the same policies as imports. [*This is an
>> important consideration. What has happened in Ottawa and Toronto so far?
>> Have automatic processes been used?*]
>>
>> *Tim* replied that in most cases it might be appropriate to replace OSM
>> data, as he believes [*as I do for most of the cases*] that the ODB
>> footprints will be more accurate than 

Re: [Talk-ca] Importing buildings in Canada

[Nate Wessel]

In short, yes. But we should give them a clear option and a clear path 
toward doing it either way - written procedures, provide preprocessing 
scripts/help, etc.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-18 7:37 p.m., john whelan wrote:
> But also - sorry this is such a long email - we certainly should not 
be manually doing re-conflation where buildings are very dense (e.g. 
downtown Toronto) or where they have already been imported extensively 
(much of the rest of the GTA). The import plan I'm working on for 
Toronto will take care of most of this automatically by importing only 
in the sparse gaps between existing OSM buildings. For other parts of 
Canada, this may not be much of an issue at all - I wouldn't know.


My interpretation is you're happy to leave this call to the local 
coordinator?  If they have no buildings it's fairly simple if there 
are buildings already mapped it becomes more complex.


Thanks John

On Sat, 18 Jan 2020 at 19:12, Nate Wessel > wrote:


Hi all,

Daniel, thanks for continuing to prod the conversation along :-)

I guess the point of disagreement here is that I generally don't
agree that the ODB buildings are of higher quality than what's
already in OSM. The ODB data I've seen is quite messy, and IMO
only marginally better than having no data in an area, especially
if not properly checked and conflated with surrounding OSM data.
People seem to generally disagree with that perspective though, so
I'll assume that other areas are better represented by their
respective ODB data sources. Central Toronto may just not have
been well mapped by the City's GIS dept; it certainly isn't the
easiest thing to get right.

My real worry here is that someone will be carelessly going
through an import replacing geometries and will destroy the work
of an editor like myself who carefully contributed their time to
make a neat and accurate map. I know for certain I've contributed
better data in Toronto than what's available from government
sources for the same area.

We must recall that governments produce building footprints in the
same way that we do - usually by tracing imagery, and there is
little reason to suppose that their data is better or more
accurate just because it comes from a seemingly authoritative
source. It comes from interns - likely interns with outdated
software and low-resolution surveys.

All that being said, I think my real reluctance to go with the
flow here stems from the haste and carelessness of the original
importers in the GTA. We're working toward a process that should
be very different from theirs though and I probably need to just
trust that our process will be calmer, slower, and more
thoughtful. If it is, I can get on board.

But also - sorry this is such a long email - we certainly should
not be manually doing re-conflation where buildings are very dense
(e.g. downtown Toronto) or where they have already been imported
extensively (much of the rest of the GTA). The import plan I'm
working on for Toronto will take care of most of this
automatically by importing only in the sparse gaps between
existing OSM buildings. For other parts of Canada, this may not be
much of an issue at all - I wouldn't know.

Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:


Bonjour groupe,

Here is a sequential summary of the last exchanges. I inserted
some comments […] within these exchanges description and
summarize what I understand from it at the end.

*Nate*asked not to confuse the process of importing new data with
that of updating/modifying existing OSM data in order to keep
things simple for this import.

*Daniel*(I) responded that importing new data and
updating/modifying existing ones at the same time (when
necessary) is not unusual in OSM [/and would be more efficient/].

*John*replied that importing new data and updating/modify
existing data when required worked quite nicely when importing
Ottawa.

*Nate *explained he believes that the buildings will not be
compared manually since there are hundreds of thousands of them
in OSM for Toronto alone. In other words, he thinks there will be
automated edits, and these edits are not governed by the same
policies as imports. [/This is an important consideration. What
has happened in Ottawa and Toronto so far? Have automatic
processes been used?/]

*Tim*replied that in most cases it might be appropriate to
replace OSM data, as he believes [/as I do for most of the
cases/] that the ODB footprints will be more accurate than
existing buildings. However he considers 

Re: [Talk-ca] Importing buildings in Canada

[john whelan via Talk-ca]

> But also - sorry this is such a long email - we certainly should not be
manually doing re-conflation where buildings are very dense (e.g. downtown
Toronto) or where they have already been imported extensively (much of the
rest of the GTA). The import plan I'm working on for Toronto will take care
of most of this automatically by importing only in the sparse gaps between
existing OSM buildings. For other parts of Canada, this may not be much of
an issue at all - I wouldn't know.

My interpretation is you're happy to leave this call to the local
coordinator?  If they have no buildings it's fairly simple if there are
buildings already mapped it becomes more complex.

Thanks John

On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:

> Hi all,
>
> Daniel, thanks for continuing to prod the conversation along :-)
>
> I guess the point of disagreement here is that I generally don't agree
> that the ODB buildings are of higher quality than what's already in OSM.
> The ODB data I've seen is quite messy, and IMO only marginally better than
> having no data in an area, especially if not properly checked and conflated
> with surrounding OSM data. People seem to generally disagree with that
> perspective though, so I'll assume that other areas are better represented
> by their respective ODB data sources. Central Toronto may just not have
> been well mapped by the City's GIS dept; it certainly isn't the easiest
> thing to get right.
>
> My real worry here is that someone will be carelessly going through an
> import replacing geometries and will destroy the work of an editor like
> myself who carefully contributed their time to make a neat and accurate
> map. I know for certain I've contributed better data in Toronto than what's
> available from government sources for the same area.
>
> We must recall that governments produce building footprints in the same
> way that we do - usually by tracing imagery, and there is little reason to
> suppose that their data is better or more accurate just because it comes
> from a seemingly authoritative source. It comes from interns - likely
> interns with outdated software and low-resolution surveys.
>
> All that being said, I think my real reluctance to go with the flow here
> stems from the haste and carelessness of the original importers in the GTA.
> We're working toward a process that should be very different from theirs
> though and I probably need to just trust that our process will be calmer,
> slower, and more thoughtful. If it is, I can get on board.
>
> But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe,
>
> Here is a sequential summary of the last exchanges. I inserted some
> comments […] within these exchanges description and summarize what I
> understand from it at the end.
>
> *Nate* asked not to confuse the process of importing new data with that
> of updating/modifying existing OSM data in order to keep things simple for
> this import.
>
> *Daniel* (I) responded that importing new data and updating/modifying
> existing ones at the same time (when necessary) is not unusual in OSM [*and
> would be more efficient*].
>
> *John* replied that importing new data and updating/modify existing data
> when required worked quite nicely when importing Ottawa.
>
> *Nate *explained he believes that the buildings will not be compared
> manually since there are hundreds of thousands of them in OSM for Toronto
> alone. In other words, he thinks there will be automated edits, and these
> edits are not governed by the same policies as imports. [*This is an
> important consideration. What has happened in Ottawa and Toronto so far?
> Have automatic processes been used?*]
>
> *Tim* replied that in most cases it might be appropriate to replace OSM
> data, as he believes [*as I do for most of the cases*] that the ODB
> footprints will be more accurate than existing buildings. However he
> considers it is a case-by-case decision [*then no automation process
> should be used*].
>
> *John* couldn’t resist digressing toward the “Microsoft buildings import”
> but had to bring back the discussion on ODB import after reactions from
> *Tim* and *Pierre* (LOL).
>
>
>
> I think that, somehow, we could all agree on how the import should be done:
>
> -  Align images on ODB, unless evidence ODB data are ill located.
>
> -  Align existing OSM content with the image, *only* 

Re: [talk-au] Maxar bushfire imagery

[Graeme Fitzpatrick]

On Sun, 19 Jan 2020 at 09:43, Andrew Harvey 
wrote:

> You can take one of the URLs from above, but without the "tms:" at the
> start eg.
>
> https://{switch:a,b,c,d}.
> tiles.mapbox.com/v4/openstreetmapau.10300100921A2B00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w
> 
>
> and in iD under the list of background layers at the bottom you should see
> "Custom", click the "..." and paste in the URL.
>

Thanks, Andrew.

That's what I thought & tried, but the map in iD doesn't move from where I
started & just stays dark?

I'm guessing that you have to be already looking at the correct area to
start using this imagery?

Is there any way of finding / working out just whereabouts ^ refers to?

  Thanks

Graeme

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

Re: [Talk-ca] Importing buildings in Canada

[Nate Wessel]

Hi all,

Daniel, thanks for continuing to prod the conversation along :-)

I guess the point of disagreement here is that I generally don't agree 
that the ODB buildings are of higher quality than what's already in OSM. 
The ODB data I've seen is quite messy, and IMO only marginally better 
than having no data in an area, especially if not properly checked and 
conflated with surrounding OSM data. People seem to generally disagree 
with that perspective though, so I'll assume that other areas are better 
represented by their respective ODB data sources. Central Toronto may 
just not have been well mapped by the City's GIS dept; it certainly 
isn't the easiest thing to get right.


My real worry here is that someone will be carelessly going through an 
import replacing geometries and will destroy the work of an editor like 
myself who carefully contributed their time to make a neat and accurate 
map. I know for certain I've contributed better data in Toronto than 
what's available from government sources for the same area.


We must recall that governments produce building footprints in the same 
way that we do - usually by tracing imagery, and there is little reason 
to suppose that their data is better or more accurate just because it 
comes from a seemingly authoritative source. It comes from interns - 
likely interns with outdated software and low-resolution surveys.


All that being said, I think my real reluctance to go with the flow here 
stems from the haste and carelessness of the original importers in the 
GTA. We're working toward a process that should be very different from 
theirs though and I probably need to just trust that our process will be 
calmer, slower, and more thoughtful. If it is, I can get on board.


But also - sorry this is such a long email - we certainly should not be 
manually doing re-conflation where buildings are very dense (e.g. 
downtown Toronto) or where they have already been imported extensively 
(much of the rest of the GTA). The import plan I'm working on for 
Toronto will take care of most of this automatically by importing only 
in the sparse gaps between existing OSM buildings. For other parts of 
Canada, this may not be much of an issue at all - I wouldn't know.


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:


Bonjour groupe,

Here is a sequential summary of the last exchanges. I inserted some 
comments […] within these exchanges description and summarize what I 
understand from it at the end.


*Nate*asked not to confuse the process of importing new data with that 
of updating/modifying existing OSM data in order to keep things simple 
for this import.


*Daniel*(I) responded that importing new data and updating/modifying 
existing ones at the same time (when necessary) is not unusual in OSM 
[/and would be more efficient/].


*John*replied that importing new data and updating/modify existing 
data when required worked quite nicely when importing Ottawa.


*Nate *explained he believes that the buildings will not be compared 
manually since there are hundreds of thousands of them in OSM for 
Toronto alone. In other words, he thinks there will be automated 
edits, and these edits are not governed by the same policies as 
imports. [/This is an important consideration. What has happened in 
Ottawa and Toronto so far? Have automatic processes been used?/]


*Tim*replied that in most cases it might be appropriate to replace OSM 
data, as he believes [/as I do for most of the cases/] that the ODB 
footprints will be more accurate than existing buildings. However he 
considers it is a case-by-case decision [/then no automation process 
should be used/].


*John*couldn’t resist digressing toward the “Microsoft buildings 
import” but had to bring back the discussion on ODB import after 
reactions from *Tim* and *Pierre* (LOL).


I think that, somehow, we could all agree on how the import should be 
done:


-Align images on ODB, unless evidence ODB data are ill located.

-Align existing OSM content with the image, *only* if necessary after 
aligning the image with ODB.


-Import non-existent buildings in OSM.

-Conflate ODB and OSM buildings, *only* if necessary.

-

To address Nate’s legitimate concerns, we could agree that there will 
be *no* automatic changes/conflation of existing buildings. Having a 
local import manager and by using the task manager, we should be able 
to ensure that there will be no unauthorized import (i.e. not 
responding to the above).


Am I too optimistic?

Daniel


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Donat ROBAUX]

Hello,

J'avais traité le cas des arrondissements parisiens. Comme les
arrondissements lyonnais et marseillais n'avaient pas été fait et devaient
être traités manuellement, je m'y suis collé.
J'aimerais qu'une âme charitable puisse vérifier l'intégration manuelle que
j'ai réalisée. Il se peut que je n'ai pas eu les yeux en face des trous.

Sinon je vois dans la liste quelques départements avec une commune non Maj
mais sans possibilité de le faire car elle n’apparaît plus dans le tableau
par département. Quelqu'un a une idée de ce que ca peut être?

Donat



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

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

Re: [talk-au] Maxar bushfire imagery

[Andrew Harvey]

You can take one of the URLs from above, but without the "tms:" at the
start eg.

https://{switch:a,b,c,d}.
tiles.mapbox.com/v4/openstreetmapau.10300100921A2B00/{zoom}/{x}/{y}.jpg?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcGF1IiwiYSI6ImNqbWl3bXZ6aDA0MTkzd21xdnV1d2k0azEifQ.HYkMOqH_E2fYd1b0oXRe6w


and in iD under the list of background layers at the bottom you should see
"Custom", click the "..." and paste in the URL.

You can get an idea of the coverage at
https://gist.github.com/andrewharvey/57da8ad7f9f425d4c811e6cd33b2fdcb#file-index-geojson

I'm still working on making it easier to consume these.

On Sun, 19 Jan 2020 at 08:36, Graeme Fitzpatrick 
wrote:

> Load into iD to start with!
>
> Thanks
>
> Graeme
>
>
> On Sat, 18 Jan 2020 at 23:18, Andrew Harvey 
> wrote:
>
>> How to load into iD/JOSM or how to make use of it for mapping?
>>
>> On Sat, 18 Jan 2020 at 08:24, Graeme Fitzpatrick 
>> wrote:
>>
>>> Thanks for putting these up Andrew.
>>>
>>> The silly question though is how do we use them? :-)
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[marc marc]

Le 18.01.20 à 18:10, Stéphane Péneau a écrit :
> J'ai été assez surpris d'un commentaire sur linuxfr, qui citait
> OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir
> demandé comment il en était arrivé à cette conclusion, sa réponse [2] me
> donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?
> 
> [1] https://linuxfr.org/nodes/119088/comments/1796042
> 
> [2] https://linuxfr.org/nodes/119088/comments/1796846

il y a beaucoup de "caricature simpliste d'un monde complexe"
mais je trouve qu'il y a quand même un part de vrai :
les serveurs osm.org de rendu par exemple, c'est un exemple de pelote,
tellement emmelé que leur évolution a du mal.

ceci dit, là où il se trompe à mes yeux, c'est que l'empilement permet
de réutiliser des briques simples au lieu d'inventer un nouveau Xieme
protocole ou Xieme brique qui fait quasi pareil que l'existant mais qui
a 1% de différence "d'optimisation" et qui au final rendra le moins
performant ou moins facile à maintenir (parce qu'à chaque amélioration
de la brique standard, il faudra du temps pour maintenir
le fork optimisé). On a cela pas loin...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Maxar bushfire imagery

[cameron]

I saw your last message about having a task server too, and was going to say 
that I'd be happy to look into running one though I don't have the ability to 
right at this point. But in a month or so I should be able to give it a go.


From: "Sebastian S." 
Sent: Sunday, 19 January 2020 8:33 am
To: talk-au@openstreetmap.org; Graeme Fitzpatrick; Andrew Harvey
Cc: OSM Australian Talk List
Subject: Re: [talk-au] Maxar bushfire imagery

Another good use case for an Australian or Oceania centric task server.

Any takers?

On 19 January 2020 8:36:03 am AEDT, Graeme Fitzpatrick  
wrote:
>
> Load into iD to start with!
>
> Thanks
>
> Graeme
>
>
> On Sat, 18 Jan 2020 at 23:18, Andrew Harvey  wrote:
>>
>> How to load into iD/JOSM or how to make use of it for mapping?
>>
>> On Sat, 18 Jan 2020 at 08:24, Graeme Fitzpatrick  
>> wrote:
>>>
>>> Thanks for putting these up Andrew.
>>>
>>> The silly question though is how do we use them? :-)
>>>
>>> Thanks
>>>
>>> Graeme___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Teaching cyclists how to contribute to OSM

[James]

Bike advocacy group in Ottawa created this:

https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md

as well as a crowd sourced map like the one for winter bike trails that
allows a user to submit if a path is winter maintained or not, it will then
update OSM in the back end: maps.bikeottawa.ca

On Sat., Jan. 18, 2020, 5:56 p.m. Erwin Olario,  wrote:

> Hi Volker.
>
> In Manila, we are promoting this MapContrib instance [0]  to get bikers
> and mobility advocates to contribute bike-related facilities on the map.
>
> For mobile tools, we teach and recommend OsmAnd (mainly because of the
> OsmAnd live feature, which allows users to update the offline database
> immediately) , but in the end we aso tell them about other mobile tools
> (and the caveat about delays in the updates)
>
> [0]: bit.ly/mapthatrack
>
> On Sun, Jan 19, 2020, 05:43 Volker Schmidt  wrote:
>
>> Has anyone produced specific teaching material specifically to get
>> cyclists involved in OSM.
>> It should be suitable for a workshop approach.
>>
>> Volker
>> Italy
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Teaching cyclists how to contribute to OSM

[Erwin Olario]

Hi Volker.

In Manila, we are promoting this MapContrib instance [0]  to get bikers and
mobility advocates to contribute bike-related facilities on the map.

For mobile tools, we teach and recommend OsmAnd (mainly because of the
OsmAnd live feature, which allows users to update the offline database
immediately) , but in the end we aso tell them about other mobile tools
(and the caveat about delays in the updates)

[0]: bit.ly/mapthatrack

On Sun, Jan 19, 2020, 05:43 Volker Schmidt  wrote:

> Has anyone produced specific teaching material specifically to get
> cyclists involved in OSM.
> It should be suitable for a workshop approach.
>
> Volker
> Italy
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Maxar bushfire imagery

[Sebastian S.]

Another good use case for an Australian or Oceania centric task server.

Any takers?

On 19 January 2020 8:36:03 am AEDT, Graeme Fitzpatrick  
wrote:
>Load into iD to start with!
>
>Thanks
>
>Graeme
>
>
>On Sat, 18 Jan 2020 at 23:18, Andrew Harvey 
>wrote:
>
>> How to load into iD/JOSM or how to make use of it for mapping?
>>
>> On Sat, 18 Jan 2020 at 08:24, Graeme Fitzpatrick
>
>> wrote:
>>
>>> Thanks for putting these up Andrew.
>>>
>>> The silly question though is how do we use them? :-)
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Supermarché drive only

[marc marc]

Le 18.01.20 à 20:25, Cédric Frayssinet a écrit :
> Le 12/01/2020 à 19:33, marc marc a écrit :
>> Le 06/01/2020 à 22:23, Cédric Frayssinet a écrit :
>>> Avez-vous déjà tagué ce genre de magasin :
>>> https://westnordost.de/p/7258.jpg
>> si c'était un drive only
>> shop=supermarket
>> drive_through=only
>>
>> mais à voir la photo, ce n'est pas le cas,
>> tu sorts de ton véhicule et tu vas dans le magasin,
>> comme n'importe quel autre magasin sauf que t'as passé
>> ta commande avant au lieu de sur place.
>> je n'ai pas connaissance de tag disant que le magasin
>> a la possibilité de commander en ligne.
>> si tu le trouve, suffit de mettre =only
> 
> 
> Du coup, j'ai pris exemple sur les lockers Amazon et j'ai mis ces tags :

c'est une bonne idée. mais je ne suis pas d'accord avec qlq détails :

> vending=parcel_pickup

vending c'est le produit vendu (le truc avec lequel tu repart)
On n'y vend pas des "parcel_pickup",
On y vend de la nourriture, boisson et autre.

> covered=yes

cela n'avait pas l'air d'être couvert mais dans un bâtiment.

> description=Consignes permettant de retirer ses courses 24h/24h

virer le 24h/24 puisqu'il se trouve dans un tag (sinon on finit
inutilement par copier tous les tags dans description)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Importing buildings in Canada

[Daniel @jfd553]

Bonjour groupe,
Here is a sequential summary of the last exchanges. I inserted some comments 
[…] within these exchanges description and summarize what I understand from it 
at the end.
Nate asked not to confuse the process of importing new data with that of 
updating/modifying existing OSM data in order to keep things simple for this 
import.
Daniel (I) responded that importing new data and updating/modifying existing 
ones at the same time (when necessary) is not unusual in OSM [and would be more 
efficient].
John replied that importing new data and updating/modify existing data when 
required worked quite nicely when importing Ottawa.
Nate explained he believes that the buildings will not be compared manually 
since there are hundreds of thousands of them in OSM for Toronto alone. In 
other words, he thinks there will be automated edits, and these edits are not 
governed by the same policies as imports. [This is an important consideration. 
What has happened in Ottawa and Toronto so far? Have automatic processes been 
used?]
Tim replied that in most cases it might be appropriate to replace OSM data, as 
he believes [as I do for most of the cases] that the ODB footprints will be 
more accurate than existing buildings. However he considers it is a 
case-by-case decision [then no automation process should be used].
John couldn’t resist digressing toward the “Microsoft buildings import” but had 
to bring back the discussion on ODB import after reactions from Tim and Pierre 
(LOL).

I think that, somehow, we could all agree on how the import should be done:

-  Align images on ODB, unless evidence ODB data are ill located.

-  Align existing OSM content with the image, only if necessary after 
aligning the image with ODB.

-  Import non-existent buildings in OSM.

-  Conflate ODB and OSM buildings, only if necessary.

-
To address Nate’s legitimate concerns, we could agree that there will be no 
automatic changes/conflation of existing buildings. Having a local import 
manager and by using the task manager, we should be able to ensure that there 
will be no unauthorized import (i.e. not responding to the above).
Am I too optimistic?
Daniel


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

Re: [OSM-talk-fr] Conciergerie ?

[marc marc]

Le 18.01.20 à 19:30, Cédric Frayssinet via Talk-fr a écrit :
> chaîne de conciergerie technique : http://lesjules.com/

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

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[marc marc]

Le 18.01.20 à 19:03, Philippe Verdy a écrit :
> Le cas "private" ne devrait pas exister pour les stations de recharge

réponse d'un gars qui en ajoute :
un jour je passes devant un immeuble, il y une borne, je l'ajoutes dans osm.
la fois d'après que t'y vas, tu vas en avance pour noter les détails
(opérateur, prise, ...) et là t'apprends que c'est d'accès privé.
supprimer la borne d'osm serait une erreur parce que le prochain va
refaire la même recherche une 2ieme fois.
alors access=private a tous son sens... surtout que la prochaine fois
j'irai discuter avec le gars voir s'il n'a pas envie de la rendre dispo
à la demande comme un autre l'a fait avant lui.
ouais le collaboratif, c'est pas que osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Conciergerie ?

[Philippe Verdy]

En quoi ça ce distingue des autres services à domicile (chauffagistes,
plombiers, jardiniers, décorateurs, voire aussi ménage, repassage, visite à
domicile comme ce que propose maintenant la poste, etc.).
Il n'y a pas un tag générique pour les services B2C, même s'ils ont une
agence et pas qu'un numéro de téléphone ou des cartons déposés dans les
boites ?
(Et je ne pense pas qu'ils s'adressent seulement aux particuliers, leurs
clients peuvent être toute entreprise aussi, et autres commerces).

Je verrais un truc du genre "service=b2c"

Ici c'est peu spécialisé puisque c'est multiservice (de nombreux commerces
sont maintenant multiservice aussi : banques, postes, stations-service,
buralistes, magasins de bouche, même les restaurants... avec des relais
colis, et ça s'est développé en même temps que la vente directe sur
Internet; on en aura de plus en plus et de moins en moins de magasins
spécialisés et de plus en plus de points locaux servant juste
d'intermédiaires, de la même façon que le commerce B2B avec des tas
d'intermédiaires entre entreprises sans presque plus aucune spécialité,
juste un carnet d'adresses de clients et de fournisseurs)


Le sam. 18 janv. 2020 à 19:31, Cédric Frayssinet via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

>
> Bonsoir à tous,
>
> S'est installée dans mon quartier cette chaîne de conciergerie technique :
> http://lesjules.com/
>
> Vous taguez cela comment ?
>
> Merci :)
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Philippe Verdy]

Je crois que ce qui est demandé est à la limite de la violation de vie
privée. Je ne vois pas l'intérêt de taguer de simples équipements à usage
strictement privé. Sinon on va taguer dans OSM ceux qui ont un téléviseur
chez eux ou les appartements où l'occupant chante sous la douche (je
plaisante), ou les affiliations politiques et votes adresse par adresse ou
l'adresse privée des élus (là je ne plaisante pas).

A moins que cela occupe un terrain avec une demande de permis de construire
nécessaire (cas des parkings, l'artificialisation du sol doit être
déclarée), une borne est un simple équipement. Cela n'a d'intérêt dans OSM
que si cela peut rendre servir aux autres (sous condition éventuelle, comme
le cas "customers" pour la recharge réservée aux clients de l'hôtel et que
l'hôtel annonce à ses clients et fait payer éventuellement parmi les
prestations proposées).

Le cas "private" ne devrait pas exister pour les stations de recharge
électrique non mises à disposition, que le propriétaire peut installer ou
enlever quand il veut et n'a pas obligation non plus de garder en service.
On verra le jour où ce sera soumis à déclaration obligatoire (mais là c'est
limite, dans le cas des téléviseurs, moins concernant les piscines et
étangs "privés" ou les puits, qui sont des ressources en eau ou qui en
utilisent avec un droit d'accès pour la collectivité et des restrictions
préfectorales pour les remplissages ou l'utilisation privée de l'eau).



Le sam. 18 janv. 2020 à 12:56, Vincent Bergeot  a
écrit :

> Le 18/01/2020 à 12:25, Shohreh a écrit :
> > Merci.
> >
> > Donc a priori, il n'y a pas de bonne solution permettant d'utiliser OSM
> pour
> > récupérer une carte des prises disponibles en France, en distinguant les
> > prises en accès privé/public ?
>
> je dirais qu'avant d'avoir la bonne solution pour récupérer les données
> il faudrait que ces données soient dans OSM avec les tags adéquats  et
> sans doute que la qualification suffisamment fine des données n'est pas
> encore là - cette qualification est possible (private, customers, ...)
>
> à plus
>
>
> --
> Vincent Bergeot
>
>
> ___
> 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-es] hello, first message tried in this list

[Philippe Verdy]

Thanks for that reply. I tried to communicate twitch the only working
channel (the OSM talk list has various issues and automatically
unsubscribes many users for technical reasons, mainly issues on the
configuration of their servers: the MLM does not deliver mails to
subscribers, they are frequently bounced due to this).

I had attempted to use it several times. I used the changeset comments to
discuss that, but blocking me via the DWG (without even any contact via the
OSM personal messages or direct emails to me) is really unfair, and
precipitated. It's largely overreactive.

but my OSM block (repeated instantly without notice while I was talking)
has also the effect that it blocks all sorts of communication in OSM. I did
not want to hurt any one but try to make things consistently.

I know that comarcas are not defined nationally by law. But each region
(autonomous community) has an official status of autonomy that defines
their own divisions, which are the legacy provinces, but with now very
limited powers, and the comarcas and municipalities.

In addition municipalities can group together for some objectives of
cooperation (this is completely similar to French intercommunalities,
except that some of them are also recognized nationally and have a fiscal
autonomy and are even now required by law to be impelmetned with mandatory
missions; for optional missions, they can still cooperate openly, in open
groups mixing municipalities for their territory or part of them,
departments and regions as fund providers, or some private or semi-private
institutions like chambers of commerce or agriculture, or agencies for
managing natural parks).

I also know that despite the fact that provincial can no longer define
"comarcas" with adminsitrative status, they still promote "touristic"
comarcas, more or less linked to former traditional comarcas. As well the
state (ministries) defines its own delimitations for agriculture planning
and management of national and european funds. They should not call them
"comarcas" even if they have some limited functions (only for the relevant
missions that the state can define or plan itself, however the state has to
delegate the funds and empowering of these missions to the autonomous
communities to implement them; the provinces are a sort of legacy inherited
from the Franco period; lot of things have changed at end of the 1980's
when autonomous communities got powered).

Anyway, there's still the need to manage the transition. I've found that
not just Aragon, Galicia and Catalunya have defined comarcal delimitations,
and that other regions have also regulated this (this is part of their
autonomy status, including Asturias). Not all have decided completely their
comarcal delimiation, but Aragon has done it in a law which is easy to find.

For other regions, there's no better consistant comarcal definition than
those defined by the state, i.e. agrarian comarca, which are the first kind
of classification we can make, and which is also the one decided by the
Spanish community in Wikimedia (Wikipedia, Commons and Wikidata, however
not all is very well sorted and there are lot of works as all kinds of
comarcas are also described, documented, but not properly sorted by kind;
the variosu images and annexes present different point of views based on
one definition or another or different times). I just used what is the
currrent best classification (on which contributors find things easily, but
I do not exclude the existence of others.

But not sorting the municipalities in Spain does not help to locate them:
they have conflicting names, so they use various suffixes to disambiguate
them, and this is also complicated by the linguistic divisions (mainly: the
national official Spanish/Castillian language, plus Galician, Estremaduran,
Asturian, Basque, Catalan, and its minor Valencian and Balearic variants)
which is used in official names of municipalities (showing dual languages:
Spanish+regional, and some smaller parts with Occitan, or French in Val
d'Aran) and in some comarcas officialized by the region (this is the case
in Aragon).

Also what I did was to check the municipalities to make sure they don't
have broken holes (there's a complicate case in one of them, Xativa in the
Valencian community, is repeatedly broken as it is highly fragmented in a
"patchwork" way with many small fragments), ordering them, completing the
lists (there were some municipalities forgotten in provinces). Sorting them
allowed easier identification and was a step prior to classifying them and
making sure nothing was forgotten.

There's a case in Aragon where the law of comarcalization and end of 2006
forgets one municipality separated from Zaragoza some months before, i.e.
Villamayor de Gallego; the law lists Villanueva de Gallego only). But there
was a correction published in a later addenda by the region of Aragon in
its bulletin. I had to fix that as well by searches and verifications.

Even outside comarcas, 

[OSM-talk] Teaching cyclists how to contribute to OSM

[Volker Schmidt]

Has anyone produced specific teaching material specifically to get cyclists
involved in OSM.
It should be suitable for a workshop approach.

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

Re: [talk-au] Maxar bushfire imagery

[Graeme Fitzpatrick]

Load into iD to start with!

Thanks

Graeme


On Sat, 18 Jan 2020 at 23:18, Andrew Harvey 
wrote:

> How to load into iD/JOSM or how to make use of it for mapping?
>
> On Sat, 18 Jan 2020 at 08:24, Graeme Fitzpatrick 
> wrote:
>
>> Thanks for putting these up Andrew.
>>
>> The silly question though is how do we use them? :-)
>>
>> Thanks
>>
>> Graeme
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-es] hello, first message tried in this list

[Miguel Sevilla-Callejo]

Estimado Philippe,

Lo primero de todo es agradecerte el esfuerzo en atender este asunto y
unirte a la discusión sobre el tema de la comarcas que se ha iniciado por
tus ediciones en diferentes comunidades autónomas de España.

Te escribo en español pues nos comentas que lo entiendes y quiero ser más
preciso que en un tercer idioma que no es ninguno de los nuestros.

El tema de la división comarcal (por comarcas) es particular en España tal
y como te comenté en en uno de tus changesets . En realidad la situación es
diferente dependiendo de cada comunidad autónoma y no ha sido hasta muy
recientemente que se ha empezado a trasladar a OpenStreetMap y solo en
aquellos casos en los que se tenía buen conocimiento del mismo. La verdad
es que deberíamos haberlo documentado más concienzudamente en la Wiki.

Desde el punto de vista general de la organización territorial en España se
pasa del Estado a la Comunidad Autónoma y de esta a provincia y después al
municipio. La construcción de las comarcas y su desarrollo normativo ha
venido de la mano de las comunidades autónomas. Aragón y Cataluña han sido
las que realizaron una división comarcal en un principio y son las que
mejor conozco.

Aunque la Wikipedia es una fuente adecuada en muchos casos, para este, en
particular, creo que puede llevar a confusión. Ya nos ha pasado con
anterioridad que para algunos aspectos las definiciones enciclopédicas de
los colegas de Wikipedia no pueden transponer al mapa. Cuidado con esto. Es
mejor que consultes con nosotros pues somos una comunidad diferente.

Tradicionalmente han existido otras divisiones comarcales ligadas,
especialmente al temas agrarios, pero estas divisiones no son comparables
ni coinciden con las divisiones comarcales que se han desarrollado o se
están desarrollando dentro de casa comunidad autónoma.

En fin, es complicado y creo que no es comparable con la situación con
otros paises como Francia.

El que unilateralmente iniciaras algunas ediciones y no atendieras a los
criterios de los colaboradores locales ha desatado el malestar de la
comunidad y esto ha llevado a que la WDG terminara bloqueándote. Espero que
puedas entenderlo.

Te animo a leer lo que se ha escrito y recopilado sobre tus ediciones y la
polémica que has suscitado en esta misma lista de correos y espero que este
malentendido podamos solucionarlo con una mejora sustancial de la calidad
de nuestro mapa.

Sigue y lee este hilo:
https://lists.openstreetmap.org/pipermail/talk-es/2020-January/017147.html

Recibe un cordial saludo.

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

PD. Si tienes problemas con la lista de correo puedes escribirme
personalmente para ponerte en contacto con la comunidad.

On Sat, 18 Jan 2020 at 21:34, Philippe Verdy  wrote:

> Hello, I'd like to follow up on the discussion started here about me.
>
> Note: I can read perfectly Spanish, but I won't talk in Spanish as my
> writing level is too poor and could lead to more misinterpretations.
>
> I was told by a Spanish user to map missing comarcas in Aragon and then I
> was blocked for that, even if there was no "error", and there was an
> ongoing talk with existing users that did not contacted me directly on OSM
> but prefer to complain to the DWG.
>
> It is clear from the talks (and it was agreed by the comments sent to the
> changeset) that this was only a misunderstanding. And that I did not break
> anything.
>
> I talked also bout the fact that there are several competing comarcal
> delimitations. They do not exist officially at national level, but are
> effective by laws and regulations in each region (short for autonomous
> community), and that for regions that are separated in different provinces,
> the comarcal decided by regions in their official bulletin of laws does not
> take into consideration the existing province boundaries.
>
> But there were several existing consensus for this topic in related
> projects (including, but not only, Wikidata, Spnish Wikipedia, and
> Commons). And the situation is not clear as all kinds of comarcas are mixed
> together or confused (sometimes with the same name depending on their type).
>
> Anyway there was a "most common" practice existing in relevant commnities
> about what was the more relevant (the situation is complicated by the fact
> that there are "natural comarcas" or "traditional comarcas" which have
> today no official status, of that sometimes coexist at several levels (a
> traditional  "comarca" may be seen as a subcomarca of another traditional
> comarca).
>
> I did not want to promote one kind of comarcas for another, but at least
> make the existing set consistent with itself for the most common use seen
> and discussed since long in various opendata projects). Allowing then the
> separate creation of these comarcas and properly tagging them to
> differentiate them when needed was what I started.
>
> But at least one comarcal division should exist in each region.
>
> I had proposed several things, I was talking 

[talk-ph] RFC: Revised road classification scheme (round 2)

[Jherome Miguel]

It has been 2-3 months since we shared ideas and opinions on a refined and
revised road classification scheme, but discussions have stalled.

So far, my proposal has been like this (for a detailed proposal, see
https://wiki.openstreetmap.org/wiki/Philippines/Mapping_conventions/Roads):

-Motorway - controlled-access expressway. Access via ramps only, and no
entry for pedestrians, bicycles, motorcycles with engine displacement below
400cc, tricycles, and animal-drawn vehicles.
-Trunk - highway between major cities (with population 100,000+), and
forming the national road transportation backbone; expressways that do not
have control of access; major roads resembling expressways (with ramps,
U-turns replacing left turns across median, and
flyovers/overpasses/underpasses at high-traffic intersections) but with
intersections and property accesses.
-Primary - (rural) highway between small cities and large town centers;
(urban) major thoroughfares, usually avenues or boulevards
-Secondary - (rural) roads between small town centers; (urban) minor
arteries, usually one connecting 3+ barangays or city districts
-Tertiary - (rural) roads between barangays (urban), collector roads,
usually one within a barangay or city district.
-Unclassified - (rural) other smaller local roads, usually one connecting
house clusters, or sitios/puroks; (urban) non-residential local streets
-Residential - Residential streets, regardless of width
-Service - property access roads, alleys, drive-thrus, driveways
-Track - farm tracks, roads only passable to 4x4/4WD vehicles, golf course
roads used only by golf carts.
-Pedestrian - streets closed to motor vehicles, or pedestrian squares

Have been mapping in Canada for 2 years and finding the road classification
scheme there better and ideal (with a good distinction between urban and
rural roads), I am considering using them as a base for a new road
classification scheme for the Philippines, but with some modifications.

I previously considered retaining the living_street classification as there
is some consensus to keep it for any street with width below 3 m or passage
hindered by obstructions. However, since the successful roadside clearing
operations in 2019 have changed the situation on the ground, there is no
legally defined concept that equals to "living street" in the Philippine
traffic code (RA 4136) or accompanying laws, and objections have been
raised on the incorrect use of the tag to mark very narrow streets in
developing countries aside from the Philippines, I strongly agree dropping
it completely at all.

There has been no consensus on handling highway bypasses or diversion
roads, so the classification should be based on their overall usage or
characteristics. My thoughts is to move the higher classification to the
bypass or diversion if most through traffic take that when traveling
through around the city or town proper (downtown or "poblacion" area),
otherwise, tag both routes with the same classification and tag the
implicit default speeds for routing engines to use.

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

[Talk-es] hello, first message tried in this list

[Philippe Verdy]

Hello, I'd like to follow up on the discussion started here about me.

Note: I can read perfectly Spanish, but I won't talk in Spanish as my
writing level is too poor and could lead to more misinterpretations.

I was told by a Spanish user to map missing comarcas in Aragon and then I
was blocked for that, even if there was no "error", and there was an
ongoing talk with existing users that did not contacted me directly on OSM
but prefer to complain to the DWG.

It is clear from the talks (and it was agreed by the comments sent to the
changeset) that this was only a misunderstanding. And that I did not break
anything.

I talked also bout the fact that there are several competing comarcal
delimitations. They do not exist officially at national level, but are
effective by laws and regulations in each region (short for autonomous
community), and that for regions that are separated in different provinces,
the comarcal decided by regions in their official bulletin of laws does not
take into consideration the existing province boundaries.

But there were several existing consensus for this topic in related
projects (including, but not only, Wikidata, Spnish Wikipedia, and
Commons). And the situation is not clear as all kinds of comarcas are mixed
together or confused (sometimes with the same name depending on their type).

Anyway there was a "most common" practice existing in relevant commnities
about what was the more relevant (the situation is complicated by the fact
that there are "natural comarcas" or "traditional comarcas" which have
today no official status, of that sometimes coexist at several levels (a
traditional  "comarca" may be seen as a subcomarca of another traditional
comarca).

I did not want to promote one kind of comarcas for another, but at least
make the existing set consistent with itself for the most common use seen
and discussed since long in various opendata projects). Allowing then the
separate creation of these comarcas and properly tagging them to
differentiate them when needed was what I started.

But at least one comarcal division should exist in each region.

I had proposed several things, I was talking about them, but I was blocked
twice in a row during these talks (and was even blocked from continuing
these talks or even read the comments).



Now I've tried several times to join this list, but the OSM MLM has
technical problems as it does not comply to the enforcement measures taken
by various ISP (including very large ones): since about one year (March
2019) many ISP have enforced these rules, notably DKIM and DMARC for their
mails, but the OSM MLM breaks the DKIM and DMARC digital signatures (by
modifying digitally signed parts of emails: some MIME headers, the mail
subject line and/or the content body. To do that on messages signed with
DKIM or DMARC by their original sender, the MLLM must take some care: it
must sign again its own modifications and update its DNS to conform to DKIM
and DMARC. But it does not, only the SPF protocol is used, and then the SPF
protocol breaks again because the OSM MLM is not the original sender. Mails
sent for the OSM MLM are then bouncing.

And now recently the OSM MLM has been *silently* dropping subscriptions
from their lists. It has done that massively. Many users can no longer
communicate on the OSM lists. Worse, now they want to block users because
their mails are "bouncing". This makes communication in OMS tlak list very
dangerous if not impossible. People are blocked unfairly even if they did
not usurpate anyone. They are forced to change their email, can no longer
choose their provider or loose messages from the lists that they expected
to see.

I was blocked in OSM because of repeated failure to join this list to
continue this discussion. This is very unfair. I was ready to propose
things. But the DWG overrreacted and took its own decision very fast,
ignoring the complete facts.



About the case of Avila, there are were two different kinds of comarcas in
the same province and they would have overlapped. I'm not opposed at all
(in fact I'm in favour of this) to have these two comarcal delimitations,
provided they are distinguished (not use the same kind of tags).

As well I proposed to add a separate delimitation of mancommunidades, using
a model simialr to the intercommunalities used in France (i.e.
boundary=local_authority plus some Spanish specific tags like in France
with admin_type:FR=*). These are also important in Spain, for legal and
fiscal reasons and important in the day life of Spnish residents.

Spin is not more complicate than France or other countries. The pure
hierarchical of admin_levels is not entirely satisfied in any country,
there are exceptions everywhere fro different purposes. It's just a
convenient first kind of sorting things and getting consistant results in
searches or in statistics data, graphs and maps).

OSM should be open to various uses and not require a single view. OMS is
open and should be able 

Re: [talk-cz] Uživatel pajas - les uvnitř parku

[Jan Macura]

Ahoj,

tagování lesů je více či méně nevyjasněná záležitost. Nicméně to přidání
lesů do parku mi nepřijde samo o sobě jako problematické, pokud se tam
skutečně nacházejí větší souvislé plochy stromů a nedává tak smysl mapovat
je jednotlivě jako body, resp. ze současně dostupných podkladů je to
jednodušší takto plošně.
Ta interpretace, že landuse=forest je jen takový les, jehož účelem je
získání dřeva, je podle mě nešťastná. Popis na wiki je napsaný tak, aby
zdůraznil rozdíl mezi přirozeným lesem (pralesem, natural=wood), rostoucím
přirozeně, a umělým lesem, pěstovaným, upraveným lidmi, což je právě případ
i lesíků v parcích.

H.

On Sat, 18 Jan 2020 at 19:03, Vladan Kudláč  wrote:

> Zdravím,
> narazil jsem na strakatý park na Moravském náměstí v Brně a zjistil jsem,
> že uživatel pajas  zmapoval les
> (landuse=forest )
> uvnitř městského parku (leisure=park
> ). Podle mého
> názoru to není dobré, podle definice parku je to oblast s trávou a stromy
> pro rekreaci, kdežto les s cílem získat dřevo. Uživateli jsem poslal v
> úterý zprávu ale neodpověděl, denně chrlí velké množství změn, všechny jsou
> bez komentáře a bez označení zdroje. Pokud jsou i ostatní změny v podobném
> duchu, tak to hraničí s vandalismem. Uživatel provedl 10 tisíc změn a účet
> má od roku 2010, což mě děsí. Nějaké nápady jak uživatele zastavit a poučit?
>
> changesets:
> https://www.openstreetmap.org/changeset/71505155
> https://www.openstreetmap.org/changeset/71505691
> https://www.openstreetmap.org/changeset/71505095
>
> --
> S pozdravem
> Vladan Kudláč
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] Update bus stop names

[Neil Matthews]

For an example of possible name mismatch, see the edit history for node:
https://www.openstreetmap.org/node/485404488 which is shown at
https://flic.kr/p/2igLCco

For an example of stops being amalgamated see:
https://www.openstreetmap.org/node/435846038 when
https://www.openstreetmap.org/node/485404491/history and
https://www.openstreetmap.org/node/436185070/history were deleted. See
the changeset for discussion:
https://www.openstreetmap.org/changeset/74179599

I am not the only person editting stops locally -- but none of us have
added not:name -- just tried to map what is there.

Cheers,
Neil

On 18/01/2020 18:40, Cj Malone wrote:
> Hey Neil,
>
> I don't know which nodes you are talking about, but of the ones I'm
> looking at (where "name" != name from new NaPTAN data using
> "naptan:AtcoCode"). The vast majority haven't been updated in 10 years,
> since the NaPTAN import, or one edit where "naptan:verified" was
> changed to yes.
>
> I am not doing automatic, or blind edits. It would have been helpful if
> when you changed names from NaPTAN import to surveyed you used
> "not:name", but that doesn't matter. When I make the edits I can look
> at the history of the node, and if a mapper has changed the name semi
> recently I will not change it but rather add a "fixme" describing the
> issue.
>
> Thanks,
> Cj
>
> On Sat, 2020-01-18 at 15:01 +, Neil Matthews wrote:
>> No, please don't update mismatched bus stop names "blindly".
>>
>> I've surveyed a lot locally and have updated them to the newest
>> values
>> from paper timetables -- which have newer names than on metal
>> signage.
>> They also match the names that the local council have used when
>> updating
>> OSM. A lot of names were surveyed that didn't need to be changed -- I
>> don't know how you would ensure that you didn't change them to some
>> incorrect official value. Obviously, you shouldn't be changing names
>> that weren't in the preious Naptan data -- you should at least assume
>> that they are now newer and likely to come from surveyed data.
>>
>> The best approach is either to add official_name (naptan_name?) and
>> leave "name" alone, or provide a mechanism where local mappers can
>> survey mismatches between your dataset and what is currently in OSM.
>> At
>> the very, very least you should move "name" to "old_name".
>>
>> Best regards,
>> Neil
>>
>> P.S. At least locally there are locations where several bus stops
>> have
>> been amalgamated into a single one. Also some are now
>> disused:bus_stop
>> if no services are currently stopping there.
>>
>>
>>
>> ___
>> 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] Supermarché drive only

[Cédric Frayssinet]

Le 12/01/2020 à 19:33, marc marc a écrit :
> Le 06/01/2020 à 22:23, Cédric Frayssinet a écrit :
>> Avez-vous déjà tagué ce genre de magasin :
>> https://westnordost.de/p/7258.jpg
> si c'était un drive only
> shop=supermarket
> drive_through=only
>
> mais à voir la photo, ce n'est pas le cas,
> tu sorts de ton véhicule et tu vas dans le magasin,
> comme n'importe quel autre magasin sauf que t'as passé
> ta commande avant au lieu de sur place.
> je n'ai pas connaissance de tag disant que le magasin
> a la possibilité de commander en ligne.
> si tu le trouve, suffit de mettre =only


Du coup, j'ai pris exemple sur les lockers Amazon et j'ai mis ces tags :

amenity=vending_machine
vending=parcel_pickup
name=Casino Drive
covered=yes
brand=Casino
indoor=yes
description=Consignes permettant de retirer ses courses 24h/24h
opening_hours=24/7

Cédric


-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[osm . sanspourriel]

Le 18/01/2020 à 19:05, Vincent Bergeot - vinc...@bergeot.org a écrit :


L’effet Dunning-Kruger, ou effet de surconfiance, est un biais
cognitif selon lequel les moins qualifiés dans un domaine surestiment
leur compétence.


Autrement dit : ne rien dire c'est prendre le risque de passer pour un con.
Dire c'est risquer de le prouver.
On le remerciera d'avoir levé l’ambiguïté^^.

Dans un premier temps il dit qu'en parlant d'OpenStreetMap il ne sait
pas de quoi il parle.
Alors tu te tais du con !

Ensuite il parle d'utiliser un protocole carto.

Bien justement, la carte du site utilise un XYZ, l'équivalent d'un TMS.
Mais bon je pense qu'on vient de lui donner deux nouveaux noms...

Et les données sont disponibles en PBF sur des sites FTP.

Côté performances on a vu pire.

Et sur mon téléphone portable j'ai le monde entier sur carte microSD.

En fait pas tout, je pourrais mais je ne télécharge que les pays ou
régions au besoin. Merci OSMAND.

Jean-Yvon

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

Re: [Talk-GB] Update bus stop names

[Cj Malone]

Hey Neil,

I don't know which nodes you are talking about, but of the ones I'm
looking at (where "name" != name from new NaPTAN data using
"naptan:AtcoCode"). The vast majority haven't been updated in 10 years,
since the NaPTAN import, or one edit where "naptan:verified" was
changed to yes.

I am not doing automatic, or blind edits. It would have been helpful if
when you changed names from NaPTAN import to surveyed you used
"not:name", but that doesn't matter. When I make the edits I can look
at the history of the node, and if a mapper has changed the name semi
recently I will not change it but rather add a "fixme" describing the
issue.

Thanks,
Cj

On Sat, 2020-01-18 at 15:01 +, Neil Matthews wrote:
> No, please don't update mismatched bus stop names "blindly".
>
> I've surveyed a lot locally and have updated them to the newest
> values
> from paper timetables -- which have newer names than on metal
> signage.
> They also match the names that the local council have used when
> updating
> OSM. A lot of names were surveyed that didn't need to be changed -- I
> don't know how you would ensure that you didn't change them to some
> incorrect official value. Obviously, you shouldn't be changing names
> that weren't in the preious Naptan data -- you should at least assume
> that they are now newer and likely to come from surveyed data.
>
> The best approach is either to add official_name (naptan_name?) and
> leave "name" alone, or provide a mechanism where local mappers can
> survey mismatches between your dataset and what is currently in OSM.
> At
> the very, very least you should move "name" to "old_name".
>
> Best regards,
> Neil
>
> P.S. At least locally there are locations where several bus stops
> have
> been amalgamated into a single one. Also some are now
> disused:bus_stop
> if no services are currently stopping there.
>
>
>
> ___
> 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] Conciergerie ?

[Cédric Frayssinet via Talk-fr]

Bonsoir à tous,

S'est installée dans mon quartier cette chaîne de conciergerie technique
: http://lesjules.com/

Vous taguez cela comment ?

Merci :)

Cédric

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[Jacques Lavignotte]

Le 18/01/2020 à 18:36, Christian Quest a écrit :

Hum... beau troll, non ?


Il ne parlaient pas plutôt de JOSM (troll²) ?

-> [ ]
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
On mangera ? (c) (tm)

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

[talk-cz] Uživatel pajas - les uvnitř parku

[Vladan Kudláč]

Zdravím,
narazil jsem na strakatý park na Moravském náměstí v Brně a zjistil jsem,
že uživatel pajas  zmapoval les (
landuse=forest )
uvnitř městského parku (leisure=park
). Podle mého
názoru to není dobré, podle definice parku je to oblast s trávou a stromy
pro rekreaci, kdežto les s cílem získat dřevo. Uživateli jsem poslal v
úterý zprávu ale neodpověděl, denně chrlí velké množství změn, všechny jsou
bez komentáře a bez označení zdroje. Pokud jsou i ostatní změny v podobném
duchu, tak to hraničí s vandalismem. Uživatel provedl 10 tisíc změn a účet
má od roku 2010, což mě děsí. Nějaké nápady jak uživatele zastavit a poučit?

changesets:
https://www.openstreetmap.org/changeset/71505155
https://www.openstreetmap.org/changeset/71505691
https://www.openstreetmap.org/changeset/71505095

--
S pozdravem
Vladan Kudláč
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[Christian Quest]

Hum... beau troll, non ?


Le 18/01/2020 à 18:10, Stéphane Péneau a écrit :
J'ai été assez surpris d'un commentaire sur linuxfr, qui citait 
OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir 
demandé comment il en était arrivé à cette conclusion, sa réponse [2] 
me donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?


[1] https://linuxfr.org/nodes/119088/comments/1796042

[2] https://linuxfr.org/nodes/119088/comments/1796846


Stf


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


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

[Eric SIBERT via Talk-fr]

Le 18/01/2020 à 18:10, Stéphane Péneau a écrit :
> J'ai été assez surpris d'un commentaire sur linuxfr, qui citait
> OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir
> demandé comment il en était arrivé à cette conclusion, sa réponse [2] me
> donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?


C'est un peu l'impression. Tu peux lui dire qu'OSM est bien à la base de 
données. Il y a pleins d'utilisations en aval dont le rendu par défaut. 
Ce rendu par défaut est juste un démonstrateur qui n'a pas vocation à 
être utilisé en production. Ceux qui tirent trop dessus se font bloquer. 
Libre à lui de faire son propre serveur/rendu ultra-optimisé mais le 
temps (même bénévole) c'est de l'argent. Alors, on fait des choix entre 
ressources matériels et ressources humaines.


Tout n'est pas perdu. Il faut lui montrer la démo de serveur de tuiles 
vectorielles sur rasp ;-)


Eric


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

[OSM-talk-fr] OpenStreetMap un bloatware ?

[Stéphane Péneau]

J'ai été assez surpris d'un commentaire sur linuxfr, qui citait 
OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir 
demandé comment il en était arrivé à cette conclusion, sa réponse [2] me 
donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?


[1] https://linuxfr.org/nodes/119088/comments/1796042

[2] https://linuxfr.org/nodes/119088/comments/1796846


Stf


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

Re: [Talk-GB] Update bus stop names

[Neil Matthews]

No, please don't update mismatched bus stop names "blindly".

I've surveyed a lot locally and have updated them to the newest values
from paper timetables -- which have newer names than on metal signage.
They also match the names that the local council have used when updating
OSM. A lot of names were surveyed that didn't need to be changed -- I
don't know how you would ensure that you didn't change them to some
incorrect official value. Obviously, you shouldn't be changing names
that weren't in the preious Naptan data -- you should at least assume
that they are now newer and likely to come from surveyed data.

The best approach is either to add official_name (naptan_name?) and
leave "name" alone, or provide a mechanism where local mappers can
survey mismatches between your dataset and what is currently in OSM. At
the very, very least you should move "name" to "old_name".

Best regards,
Neil

P.S. At least locally there are locations where several bus stops have
been amalgamated into a single one. Also some are now disused:bus_stop
if no services are currently stopping there.



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

[OSM-talk-fr] réparation de relations à la frontière francobelge

[Philippe Verdy]

un utilisateur de JOSM a ajouté hier soir des parcs naturels en Belgique
dont certains appuyés sur les frontières existantes et notamment toutes les
relations touchant la frontière internationale. Pour cela il a scindé
incorrectement certains chemins existants sans avoir chargé toutes les
relations dépendantes.

C'est le parc au sud de Tournai, cétait cassé sur la frontière avec
l'arrondissement de Valencienne.

Je viens de réparer (j'espère) mais je n'ai pas vérifié le reste de la
Belgique s'il y a eu d'autres scissions/fusions de chemins, juste ce qui
touchait la frontière internationale franco-belge.

J'ai averti l'utilisateur dans son changeset. Il n'avait "corrigé" que les
frontières belges, aucune des frontières françaises
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Update bus stop names

[Stuart Reynolds]

If you take a look at the map for the area, you’ll see that Redwood Close is a 
close to the east, on the bend in Mountbatten Drive. The bus stop, as can be 
seen should you happen to look at a site where there is some street imagery 
(can’t imagine which one) is actually where NaPTAN has it - directly opposite 
Silver Birch Drive. From a data perspective, I am quite happy that Silver Birch 
Drive is correct, and that Redwood Close isn’t as good as it is further away 
(and difficult to qualify with one of the standard qualifiers). What I can’t 
tell from the imagery however is what is written on the bus stop flag, and you 
would need to survey it. In an ideal world, NaPTAN fields should reflect what 
is on the flag - and it looks like a newish flag, so it should be correct.

The Bus Open Data (BOD) timetable provisions of the Bus Services Act 2017 came 
into effect from January, although there is a year-long “implementation” 
period. At present, that is only requiring timetable data from operators. 
However, having accessible information on board buses (signboards and audible 
announcements) is another aspect of BOD and the spoken / displayed official 
name is a key part of that. Debates are going on in the industry at present as 
to the recommended approach for capturing this data in NaPTAN. My 
recommendations all along have been if the name that is spoken isn’t right, 
then NaPTAN needs to be corrected. On the IOW, there is only one operator so it 
is less of a problem than where there is a multi-operator environment, but we 
need to make data sets and names align which was the whole point of 
standardisation from way back in 2003/4 (wish) when this was first introduced.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 18 Jan 2020, at 13:40, Cj Malone 
mailto:cjmal...@mail.com>> wrote:

Thanks, I didn't really understand the NaPTAN site, but your link to download 
the data really helped.

Although now I have another issue, which data source should be preferred. Take 
https://www.openstreetmap.org/node/550691387 for example, no name in OSM. It's 
napcode appears to be 23062, Southern Vectis has that as "Redwood Close" 
whereas the nap data calls it "Silverbirch Drive".

I'm going to do a survey now, and hopefully it will be clear which dataset 
should be preferred. ie does SV have outdated nap data, or do they pull the 
official nap data, make edits, but not publish that back.

Or maybe this issue could arise that the name on the bus speaker/other digital 
reference could be different to the name on the sign on the road. Then, what 
one would be name vs alt_name, but hopefully that isn't the case.

I currently only intend to add name and nap reference codes to OSM, in my 
opinion the other data like naptan:CommonName should stay in the nap dataset, 
and not be copied to OSM. OSM mappers collecting, or even just storing that 
data will just make more conflicts in the datasets.

Cj

On 18 January 2020 12:16:35 GMT, Stuart Reynolds 
mailto:stu...@travelinesoutheast.org.uk>> 
wrote:
Hi Cj,

What you have got there is Southern Vectis’s link to a subset of the current 
NaPTAN data. Please note, though, that Southern Vectis are not responsible for 
this data - that is maintained by Isle of Wight Council.

NaPTAN data is always available by local authority, or for the entire country, 
from the official source. You don’t need to have a login, and instructions can 
be found at http://naptan.app.dft.gov.uk/DataRequest/help on how to download 
individual areas. Essentially, you will need the Atcoprefix to form the URL and 
you can get this most easily by following the “last submissions” link contained 
within that page.

But all this comes with a health warning!

NaPTAN data from the official source will generally be more up to date than 
what has been imported into OSM some years ago. But I know, from when I 
proposed a mechanical edits few years ago, that many mappers have surveyed 
their local stops and would be unhappy with it being updated without a further 
survey by what they regard as an inferior source, particularly if is not well 
maintained.

Be aware of “Custom and practice” stops in NaPTAN which are unmarked. Buses 
stop there, but there isn’t something that you can see on the ground that you 
can map, necessarily. Hail and Ride stops are even worse, because they are 
virtual stops intended to give something that a scheduling system can hang a 
time on rather than an accurate representation of where a bus stops. You can 
identify all of these by BusStopType in the data.

Common errors in the official NaPTAN data set may be missing stops, or the 
inclusion of stops that are no longer in use. Some areas remove stops when they 
are no longer served, even though the infrastructure is still in place on the 
ground (wrong, in my opinion, but there you go). You may also find stops that 
are not precisely where you expect them to be, and they may also not have the 
name that is on the stop 

Re: [Talk-GB] Update bus stop names

[Cj Malone]

Thanks, I didn't really understand the NaPTAN site, but your link to download 
the data really helped.

Although now I have another issue, which data source should be preferred. Take 
https://www.openstreetmap.org/node/550691387 for example, no name in OSM. It's 
napcode appears to be 23062, Southern Vectis has that as "Redwood Close" 
whereas the nap data calls it "Silverbirch Drive".

I'm going to do a survey now, and hopefully it will be clear which dataset 
should be preferred. ie does SV have outdated nap data, or do they pull the 
official nap data, make edits, but not publish that back.

Or maybe this issue could arise that the name on the bus speaker/other digital 
reference could be different to the name on the sign on the road. Then, what 
one would be name vs alt_name, but hopefully that isn't the case.

I currently only intend to add name and nap reference codes to OSM, in my 
opinion the other data like naptan:CommonName should stay in the nap dataset, 
and not be copied to OSM. OSM mappers collecting, or even just storing that 
data will just make more conflicts in the datasets.

Cj

On 18 January 2020 12:16:35 GMT, Stuart Reynolds 
 wrote:
>Hi Cj,
>
>What you have got there is Southern Vectis’s link to a subset of the
>current NaPTAN data. Please note, though, that Southern Vectis are not
>responsible for this data - that is maintained by Isle of Wight
>Council.
>
>NaPTAN data is always available by local authority, or for the entire
>country, from the official source. You don’t need to have a login, and
>instructions can be found at
>http://naptan.app.dft.gov.uk/DataRequest/help on how to download
>individual areas. Essentially, you will need the Atcoprefix to form the
>URL and you can get this most easily by following the “last
>submissions” link contained within that page.
>
>But all this comes with a health warning!
>
>NaPTAN data from the official source will generally be more up to date
>than what has been imported into OSM some years ago. But I know, from
>when I proposed a mechanical edits few years ago, that many mappers
>have surveyed their local stops and would be unhappy with it being
>updated without a further survey by what they regard as an inferior
>source, particularly if is not well maintained.
>
>Be aware of “Custom and practice” stops in NaPTAN which are unmarked.
>Buses stop there, but there isn’t something that you can see on the
>ground that you can map, necessarily. Hail and Ride stops are even
>worse, because they are virtual stops intended to give something that a
>scheduling system can hang a time on rather than an accurate
>representation of where a bus stops. You can identify all of these by
>BusStopType in the data.
>
>Common errors in the official NaPTAN data set may be missing stops, or
>the inclusion of stops that are no longer in use. Some areas remove
>stops when they are no longer served, even though the infrastructure is
>still in place on the ground (wrong, in my opinion, but there you go).
>You may also find stops that are not precisely where you expect them to
>be, and they may also not have the name that is on the stop flag on the
>ground.
>
>That last one is a point worth dwelling on. NaPTAN is intended to be
>granular in its data. That means that the street that a stop is on
>should go into the “streetname” field, and a short name should go into
>the “commonname” field. Our advice to database administrators is that
>where there isn’t a prominent landmark (bus station, pub, etc) then
>this is most suited to a nearby side road. That way stops along a long
>road can have different names, which is essential in a journey planner
>or timetable. On the ground, though, many authorities will put
>composite names on the flags, and often the other way round if they
>consider the main road to be more important. And they then differ on
>occasion from what the operator wants to call the stop (although
>operators tend to focus on just the timetabled points). Oh, and some
>areas misuse the fields. In Sheffield (for good historic reasons, so I
>don’t want to pick on them unduly) you will find that the commonname is
>simply the stop letter e.g. CS1 which should properly be in the
>Indicator field, and the common name (which should be “Century Square”)
>is only found by looking at the stop area name.
>
>All this just goes to highlight that you will need to reflect carefully
>on what the fields that you are updating in OSM should be before making
>the changes - although I agree that in many places the data in OSM is
>way out of date and desperately needs updating.
>
>Regards,
>Stuart Reynolds
>for traveline south east and anglia
>
>On 18 Jan 2020, at 11:18, Cj Malone via Talk-GB
>mailto:talk-gb@openstreetmap.org>> wrote:
>
>Hello,
>
>I've recently found an open data set with more accurate bus stop names
>than OSM. Based on my limited survey of differences in OSM data and
>this data, theirs has been more accurate. Not really surprising, since
>it's there network, 

Re: [talk-au] Maxar bushfire imagery

[Andrew Harvey]

How to load into iD/JOSM or how to make use of it for mapping?

On Sat, 18 Jan 2020 at 08:24, Graeme Fitzpatrick 
wrote:

> Thanks for putting these up Andrew.
>
> The silly question though is how do we use them? :-)
>
> Thanks
>
> Graeme
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Update bus stop names

[Tony OSM]

Hi Guys

I imported NaPTAN data for my local area (Chorley) some months ago. Took 
the data for Lancashire and filtered on Town:Chorley. Some of the stops 
were excluded because the data had not been correctly input by reason of 
no entry, misspelt, wrong town entered.


Using the JOSM:Conflate tool enabled me to identify existing stops and 
merge/manipulate the data - hard work with some mistakes which I am now 
correcting by field survey - I know the area well so I tend to be able 
to spot errors. Conflate allows the setting of distance to match nodes - 
I started at 10 meters to get the close matches then 50 metres, several 
iteration through the data.


I would encourage you to add the fields naptan:ATCOCode & 
naptan:NaptanCode as they are useful references when using timetable 
software - all my local bus stops include NaptanCode for text alerts for 
buses.


Bus stop types - most are MKD which I think translates as marked on the 
ground, but CUS are the Custom and practice stops which Stuart refers. 
As they are not physical should they be in OSM ? Answering my own 
question - I think so because it is additional data and very useful for 
map users, but I would now put in the BusStopType field. Similar for HAR 
hail and ride.


Have a look at putting nodes in - helps to complete the map.

I found Latitude and Longitude locations to be accurate within 10 yards 
or so, more accurate than the previously entered bus stops - I surveyed 
/ used Mapillary to confirm.


Be critical about the data and your process - it helps accuracy but 
don't be afraid.


Good mapping

Regards

Tony Shield (TonyS999)

On 18/01/2020 12:16, Stuart Reynolds wrote:

Hi Cj,

What you have got there is Southern Vectis’s link to a subset of the 
current NaPTAN data. Please note, though, that Southern Vectis are not 
responsible for this data - that is maintained by Isle of Wight Council.


NaPTAN data is always available by local authority, or for the entire 
country, from the official source. You don’t need to have a login, and 
instructions can be found at 
http://naptan.app.dft.gov.uk/DataRequest/help on how to download 
individual areas. Essentially, you will need the Atcoprefix to form 
the URL and you can get this most easily by following the “last 
submissions” link contained within that page.


But all this comes with a health warning!

NaPTAN data from the official source will /generally/ be more up to 
date than what has been imported into OSM some years ago. But I know, 
from when I proposed a mechanical edits few years ago, that many 
mappers have surveyed their local stops and would be unhappy with it 
being updated without a further survey by what they regard as an 
inferior source, particularly if is not well maintained.


Be aware of “Custom and practice” stops in NaPTAN which are unmarked. 
Buses stop there, but there isn’t something that you can see on the 
ground that you can map, necessarily. Hail and Ride stops are even 
worse, because they are virtual stops intended to give something that 
a scheduling system can hang a time on rather than an accurate 
representation of where a bus stops. You can identify all of these by 
BusStopType in the data.


Common errors in the official NaPTAN data set may be missing stops, or 
the inclusion of stops that are no longer in use. Some areas remove 
stops when they are no longer served, even though the infrastructure 
is still in place on the ground (wrong, in my opinion, but there you 
go). You may also find stops that are not precisely where you expect 
them to be, and they may also not have the name that is on the stop 
flag on the ground.


That last one is a point worth dwelling on. NaPTAN is intended to be 
granular in its data. That means that the street that a stop is on 
should go into the “streetname” field, and a short name should go into 
the “commonname” field. Our advice to database administrators is that 
where there isn’t a prominent landmark (bus station, pub, etc) then 
this is most suited to a nearby side road. That way stops along a long 
road can have different names, which is essential in a journey planner 
or timetable. On the ground, though, many authorities will put 
composite names on the flags, and often the other way round if they 
consider the main road to be more important. And they then differ on 
occasion from what the operator wants to call the stop (although 
operators tend to focus on just the timetabled points). Oh, and some 
areas misuse the fields. In Sheffield (for good historic reasons, so I 
don’t want to pick on them unduly) you will find that the commonname 
is simply the stop letter e.g. CS1 which should properly be in the 
Indicator field, and the common name (which should be “Century 
Square”) is only found by looking at the stop area name.


All this just goes to highlight that you will need to reflect 
carefully on what the fields that you are updating in OSM should be 
before making the changes - although I agree that in 

[OSRM-talk] Finding Route between more than two locations using OSRM

[BATEESH .]

Hi,

I want to use OSRM routing for finding shortest route between more than two
cities.
I am trying to use the demo server available at:
http://map.project-osrm.org/ to see how a typical route with 3 or 4
locations will look like.But it is not allowing me to add more than two
locations. If i click on plus sign to add third location then it does not
work.Can you please tell me whether I can use OSRM for more than two
cities? If yes, then is it available in demo server mentioned above?

Thanks and Regards,
Bateesh
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

[Ture Pålsson]

> 18 jan. 2020 kl. 00:03 skrev Grigory Rechistov via Talk-se 
> :
> 
> Hej igen,
> Jag har uppdaterat mina skript för att upptäcka och slå samman ytterligare 
> nodpar som borde vara en nod, t ex "Stora" + "mosse" ska till "Stora mosse" 
> osv. Det fanns dock bara 5 (fem) noder att korrigera; de är nu taggade med 
> ett extra nyckelvärde note="Name is merged from parts, recheck it”.

En kommentar från sidolinjen, och utan att vilja lägga mig i diskussionen i 
stort: Jag har för mig att LMV publicerade textlagren i två uppsättningar: en 
”kart”-uppsättning med snygga avstavningar, radbrytningar och så, och en 
”GIS”-uppsättning där namnen sitter ihop. Vilket av dem är det du tittar på?

Sedan misstänker jag att även ”GIS”-uppsättningen lider lite av att vara ”en 
karta i shapefile-format”, snarare än en geodatabas — namnen är placerade där 
det blir snyggt på en 50k-karta, inte nödvändigtvis på den mest representativa 
punkten.

  — T






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

Re: [Talk-GB] Update bus stop names

[Stuart Reynolds]

Hi Cj,

What you have got there is Southern Vectis’s link to a subset of the current 
NaPTAN data. Please note, though, that Southern Vectis are not responsible for 
this data - that is maintained by Isle of Wight Council.

NaPTAN data is always available by local authority, or for the entire country, 
from the official source. You don’t need to have a login, and instructions can 
be found at http://naptan.app.dft.gov.uk/DataRequest/help on how to download 
individual areas. Essentially, you will need the Atcoprefix to form the URL and 
you can get this most easily by following the “last submissions” link contained 
within that page.

But all this comes with a health warning!

NaPTAN data from the official source will generally be more up to date than 
what has been imported into OSM some years ago. But I know, from when I 
proposed a mechanical edits few years ago, that many mappers have surveyed 
their local stops and would be unhappy with it being updated without a further 
survey by what they regard as an inferior source, particularly if is not well 
maintained.

Be aware of “Custom and practice” stops in NaPTAN which are unmarked. Buses 
stop there, but there isn’t something that you can see on the ground that you 
can map, necessarily. Hail and Ride stops are even worse, because they are 
virtual stops intended to give something that a scheduling system can hang a 
time on rather than an accurate representation of where a bus stops. You can 
identify all of these by BusStopType in the data.

Common errors in the official NaPTAN data set may be missing stops, or the 
inclusion of stops that are no longer in use. Some areas remove stops when they 
are no longer served, even though the infrastructure is still in place on the 
ground (wrong, in my opinion, but there you go). You may also find stops that 
are not precisely where you expect them to be, and they may also not have the 
name that is on the stop flag on the ground.

That last one is a point worth dwelling on. NaPTAN is intended to be granular 
in its data. That means that the street that a stop is on should go into the 
“streetname” field, and a short name should go into the “commonname” field. Our 
advice to database administrators is that where there isn’t a prominent 
landmark (bus station, pub, etc) then this is most suited to a nearby side 
road. That way stops along a long road can have different names, which is 
essential in a journey planner or timetable. On the ground, though, many 
authorities will put composite names on the flags, and often the other way 
round if they consider the main road to be more important. And they then differ 
on occasion from what the operator wants to call the stop (although operators 
tend to focus on just the timetabled points). Oh, and some areas misuse the 
fields. In Sheffield (for good historic reasons, so I don’t want to pick on 
them unduly) you will find that the commonname is simply the stop letter e.g. 
CS1 which should properly be in the Indicator field, and the common name (which 
should be “Century Square”) is only found by looking at the stop area name.

All this just goes to highlight that you will need to reflect carefully on what 
the fields that you are updating in OSM should be before making the changes - 
although I agree that in many places the data in OSM is way out of date and 
desperately needs updating.

Regards,
Stuart Reynolds
for traveline south east and anglia

On 18 Jan 2020, at 11:18, Cj Malone via Talk-GB 
mailto:talk-gb@openstreetmap.org>> wrote:

Hello,

I've recently found an open data set with more accurate bus stop names
than OSM. Based on my limited survey of differences in OSM data and
this data, theirs has been more accurate. Not really surprising, since
it's there network, and most of the OSM data hasn't been updated since
the naptan import nearly a decade ago.

I intent to start updating OSM based on this data. The legal mailing
list has OK'ed this as it's OGLv3.

I won't be importing any nodes, but I do intend for it to be "machine
assisted". I will create a report similar to
https://gregrs.dev.openstreetmap.org/fhrs/ where I will then go through
on a node by node basis and decide if the node should be updated. Any
tag I edit I will add source:name=Southern Vectis, and leave the
naptan:CommonName untouched.

While I do this I could also upgrade from highway=bus_stop to
public_transport=platform, bus=yes. Keeping the legacy tags as the wiki
recommends.

I will be using this data set https://www.islandbuses.info/open-data
the same data set is available for more regions, but at the moment I don't 
intent to use them, a local mapper would be better suited. 
https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-
ahead-group/

Any comments?

Thanks
Cj


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

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Vincent Bergeot]

Le 18/01/2020 à 12:25, Shohreh a écrit :

Merci.

Donc a priori, il n'y a pas de bonne solution permettant d'utiliser OSM pour
récupérer une carte des prises disponibles en France, en distinguant les
prises en accès privé/public ?


je dirais qu'avant d'avoir la bonne solution pour récupérer les données 
il faudrait que ces données soient dans OSM avec les tags adéquats  et 
sans doute que la qualification suffisamment fine des données n'est pas 
encore là - cette qualification est possible (private, customers, ...)


à plus


--
Vincent Bergeot


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

Re: [Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

[Andy Townsend]

Just for info, Verdy_p started editing near Zaragosa again so I've 
blocked them again, and again asked that they join this mailing list to 
discuss everything here:


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

Best Regards,

Andy Townsend (from OSM's Data Working Group)


Solo para información, Verdy_p comenzó a editar cerca de Zaragosa 
nuevamente, así que los bloqueé nuevamente, y nuevamente les pedí que se 
unieran a esta lista de correo para discutir todo aquí:


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

Atentamente,

Andy Townsend (del Grupo de trabajo de datos de OSM)

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

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Shohreh]

Merci à tous !



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

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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[deuzeffe]

Le 17/01/2020 à 08:32, Jacques Lavignotte a écrit :

Bonjour,


Bonjour,

Osmose râle sur mes récentes modifs d'hier soir (selon le mode op 
indiqué par Vincent )  :


  Attribut “population” inconsistant entre la relation et son membre 
“admin_centre”
Population du rôle “admin_centre” (309) supérieure à celle de la 
relation (305)

relation 146525

Qu'ai-je fait de mal ?


A priori, rien :)

Pour le node admin_centre, l'attribut population a une valeur de 309 et 
pour la relation, le champ population a une valeur de 305. Donc, ça coince.


J'ai regardé pour ma commune : les valeurs pour le node et la relation 
ne sont pas les mêmes :/ Moi, pour le node, j'avais inscrit la valeur de 
la population totale* (à la mimine, avant que Vincent ne lance sa 
moulinette), valeur supprimée par celui qui a fait tourner la moulinette 
pour le département, et remplacée sur la relation par la valeur de la 
population municipale.


* valeur que la commune reprend aussi (et non la population municipale...)

 Comme ce n'est toujours pas clair dans ma tête 
(admin_centre/relation, pop. total/municipale), je n'ai pas encore 
participé à l'effort commun 


--
deuzeffe

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

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[marc marc]

a noter qu'il y a aussi la clef charging_station=*
https://taginfo.openstreetmap.fr/keys/charging_station
permettant de renseigner qu'un poi a une station de recharge
lorsqu'on ignore exactement où il se trouve

au final cela fait quelques choses du genre :

area[name="Cabourg"];
nwr[amenity=charging_station]->.borne;
(
nwr(around.borne:100)[tourism=hotel];
nwr[tourism=hotel][charging_station][charging_station!=no];
);
(._;>;);
out meta;


Le 18.01.20 à 10:40, Vincent Bergeot a écrit :
> Le 18/01/2020 à 02:09, Shohreh a écrit :
>> trouver tous les hôtels en France qui proposent une
>> prise pour recharger une voiture électrique
> 
> area[name="Cabourg"];
>   node(area)[tourism=hotel]->.hotels;
>   (
>     way(around.hotels:100)[amenity=charging_station];
>     node(around.hotels:100)[amenity=charging_station];
>   );
>   (._;>;);
>   out meta;
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Yves P.]

La requête https://overpass-turbo.eu/s/PRO trouve 456 POI et 9 polygones (sans 
tenir compte de access).
Mais elle trouve des bornes de recharge de… vélos !

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

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[marc marc]

Le 18.01.20 à 12:25, Shohreh a écrit :
> distinguant les prises en accès privé/public ?

access=private/customers/yes (l'absence de la clef signifiant yes)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Shohreh]

Merci.

Donc a priori, il n'y a pas de bonne solution permettant d'utiliser OSM pour
récupérer une carte des prises disponibles en France, en distinguant les
prises en accès privé/public ?



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

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

Re: [Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

[Pepe Valverde de la Vera]

Hola buenas, sin ánimo de polemizar y solo por seguir el criterio que
mantiene osm en este asunto del ordenamiento territorial y que no es otro
que el marco legal que para ello se establece en cada País, en España y
segun la ley de bases de régimen local (legislación que es de aplicación a
nivel general) se establecen oficialmente 4 niveles de division del
territorio por debajo de las propias fronteras del Estado, a saber,
Comunidad Autónoma, Provincia, Municipio, Entidad local menor. Eso es lo
oficial y asi gráficamente lo representa la cartografia del organismo
responsable, aqui el CNIG o IGN antes. Entes administrativos y
jurídicamente independientes por tanto, con sus competencias definidas,
gestión y recursos propios.

Pero, y aqui viene el lio, el propio legislador deja abierta (art 42) a
criterio de comunidades autónomas y ayuntamientos la creacion de otras
figuras en su territorio de caracter supramunipal. Pueden ser
mancomunudades, para prestacion de servicios, no tienen marco territorial
propio, sino que es el de cada municipio que la integra pudiendo pertenecer
en algun caso a distintas CCAA o provincias distintas y tienen la duración
del propio servicio.

Tambien en este mismo "nivel" estarian las areas metropolitanas de
similares propiesades de las anteriores.

Por ultimo, las comarcas, repito que no existen como tal entidad juridica
con caracter homogeneo en España. Oficialmente, por ejemplo, en Castilla y
León solo hay una y no tienen intención de permitir que se cree ninguna
más. En cambio en Aragón,  su parlamento autonómico ha decidido
comarcalizar todo su territorio. Por tanto, en OSM solo debe aparecer como
tag o division territorial, las que lo son legalmente como El Bierzo, el
resto no lo son.

Todas las demás divisiones administrativas que existen para la gestion de
servicios publicos de las administraciones NO SON COMARCAS, son areas de
competencias e intereses aunque tengan ese nombre. Dicho con un ejemplo,
podemos dividir el territorio en comarcas agrarias, ganaderas, en diócesis,
en arciprestazgos, en grupos de accion local, en comarcas sanitarias, en
comarcas forestales o como en este caso se le ponga en su capricho al
editor de turno, pero NO SERAN COMARCAS.

Esto es lo oficial, el resto si se quiere hacer un mapa continuo, se
deberia establecer un consenso entre todo el colectivo.

Esa es mi modesta opinión, primero lo oficial y para cuando no exista
oficialidad, un criterio establecido por la propia asociacion, el resto se
deberia revertir como se hace con otras cosas.

Saludos

Pepe


El vie., 17 ene. 2020 19:39, Diego García  escribió:

> Buenas tardes.
>
> En España, las comarcas son una división del territorio que agrupa a
> varios municipios. Se intenta, me temo que a veces sin conseguirlo, que se
> correspondan a la definición de comarca, englobando una zona geográfica que
> comparte características naturales y humanas comunes, en una jerarquía por
> debajo de la región. Como tal agrupación de municipios, y establecidas por
> separado en cada comunidad, se trata de una entidad por encima del
> municipio pero por debajo de autonomía, al margen de las provincias. Se da
> el caso de que hay comarcas que incluyen municipios de diferentes
> provincias, lo que no supone ningún problema a la hora de editar, siempre
> que dejemos de lado las provincias al trabajar el tema.
>
> Por ejemplo, la comarca de la Hoya de Huesca, o la de los Monegros (en su
> mayor parte dentro de la provincia de Huesca), comprenden municipios de
> Zaragoza, sin que eso suponga un problema. No es necesario fraccionar nada,
> ni tocar las provincias, ya que son una entidad aparte, que no mantiene una
> jerarquía con las comarcas. Simplemente establecemos la frontera de las
> comarcas y las incluímos en la entidad superior, que es la autonomía. Esto
> es algo que funciona, que es como debe hacerse, y que asumimos así por
> consenso desde hace años en la comunidad española de OSM.
>
> Desde hace un par de semanas se vienen sucediendo ediciones del usuario
> Verdy_p que no están teniendo en cuenta la jerarquía que tienen las
> comarcas en España. Por ejemplo, en el caso de la comarca de la Hoya de
> Huesca la ha dividido en dos, estableciendo una "Hoya de Huesca (Zaragoza)"
> y otra "Hoya de Huesca (Huesca)", que a su vez ha incluído como partes de
> la relación que ya existía. A todas ellas les ha dado admin_level 7.
>
> https://www.openstreetmap.org/changeset/79639164
>
> Podemos decir: "bueno, es una forma de verlo, la edición es correcta".
> Pero en realidad no lo es, por tres razones:
>
> - En primer lugar, al establecer varias relaciones con el mismo
> admin_level triplica la comarca
> - En segundo lugar, se está inventando el name de las relaciones creadas.
> "Hoya de Huesca (Zaragoza)" no es algo que exista en ninguna parte.
> - En tercer lugar, es totalmente innecesario. El mapa funciona igual de
> cara a las búsquedas o a la jerarquía de territorios. De hecho, antes
> funcionaba mejor. Si ahora 

[Talk-GB] Update bus stop names

[Cj Malone via Talk-GB]

Hello,

I've recently found an open data set with more accurate bus stop names
than OSM. Based on my limited survey of differences in OSM data and
this data, theirs has been more accurate. Not really surprising, since
it's there network, and most of the OSM data hasn't been updated since
the naptan import nearly a decade ago.

I intent to start updating OSM based on this data. The legal mailing
list has OK'ed this as it's OGLv3.

I won't be importing any nodes, but I do intend for it to be "machine
assisted". I will create a report similar to
https://gregrs.dev.openstreetmap.org/fhrs/ where I will then go through
on a node by node basis and decide if the node should be updated. Any
tag I edit I will add source:name=Southern Vectis, and leave the
naptan:CommonName untouched.

While I do this I could also upgrade from highway=bus_stop to
public_transport=platform, bus=yes. Keeping the legacy tags as the wiki
recommends.

I will be using this data set https://www.islandbuses.info/open-data
the same data set is available for more regions, but at the moment I don't 
intent to use them, a local mapper would be better suited. 
https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-
ahead-group/

Any comments?

Thanks
Cj


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

Re: [talk-au] Maxar bushfire imagery

[Warin]

On 18/1/20 7:15 pm, Sebastian S. wrote:
I think the discussion regarding damaged is good, however I feel that 
this is a too fine grained quality for mapping from satellite images.


I would use ruined. Ruined can be fully destroyed or partially.



Ruined to me would be beyond economic recovery.



If damaged my next question would be how much? A little? Very 
subjective to quantify.



Damaged would be cheaper to repair rather than rebuild.


And yes there will be some that are hard to judge.

But a large number can easily be place into one category or the other.

Where it is hard to judge I'd be conservative and go for ruined.


Already have hard to determine ruined or destroyed, so I think damaged 
is far easier to determine.







On 18 January 2020 9:34:58 am AEDT, Warin <61sundow...@gmail.com> wrote:

On 17/1/20 10:08 pm, Mateusz Konieczny wrote:




17 Jan 2020, 11:42 by andrew.harv...@gmail.com:

I'm all for using the lifecycle prefix,
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. I
agreed that if there's still remains there use ruined or
destroyed, not sure what the difference is though.

ruined implies that ruins still remain, destroyed may mean that
or that there is no trace at all

in practice difference is minor if any


Most of these will still have foundations in place, they may not
be fit for reuse but they are there. Some fire places and chimneys
too remain.

I'll use ruined. Unless there are other ideas?



If there is no trace at all then 'razed' could be a better word. Of 
course there will be those that say OSM should not have that, but it 
does avoid some one adding it from old imagery.



Once it's been cleared you could use demolished, removed or
raised

Probably razed, not raised. I see not real difference.

, again not sure what the difference is. While damaged is not
documented it seems the perfect fit since there is no other
suitable tag for this on the wiki.

damaged seems to me a poor fit as prefix, damaged building is
still a building,
and I would expect building=something tag to be used.



By damaged I mean part of the building is intact but another part
has been damaged .. e.g. a truck has run part way through the
building.






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

Re: [talk-cz] Podcast o Mapy.cz (i OSM)

[Vladimír Slávik]

Dne 18.1.2020 v 10:30 Matěj Cepl napsal(a):

On 2020-01-17, 20:13 GMT, Pavel Zbytovský wrote:

tip na něco k poslechu: rozhovor s Martinem Jeřábkem šéfem
Mapy.cz, asi 5 minut slávy dostalo i OpenStreetMap. Zmíněna
byla třeba dobrá spolupráce s komunitou. Zaujal mě ještě ve
výhledu plán na přidání možnosti editace přímo do Mapy.cz.

Zmiňují, že jsou schopni najít sjezdovku s osvětlením. Bohužel
na https://wiki.openstreetmap.org/wiki/Tag:piste:type%3Ddownhill
zjišťuji, že tam na to neexistuje ani nějaké klíčové slovo. Jak
zavést diskusi na její zavedení?

Hezký den,

Matěj
V návrhu Piste na wiki [1] vidím piste:lit a kdyby to nic, myslím že 
obyčejné lit [2] bez prefixu by taky mohlo stačit - "sensible on many 
other ways, too"...


VS

[1] https://wiki.openstreetmap.org/wiki/Piste_Maps
[2] https://wiki.openstreetmap.org/wiki/Key:lit

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

Re: [Talk-es] Ediciones del usuario Verdy_p, sin consenso con la comunidad española de OSM

[sanchi]

Buenas

Una pequeña recopilación de lo que pueda faltar y ha pasado.

El tema de las comarcas en España es una cosa compleja y no homogénea.
Tampoco soy experto en la materia. Se que hay zonas que son oficiales
(pocas) y en la mayoría que no existen y no tienen uso real ni
administrativo ni nada. Si algo me equivoco decírmelo.

Creo que es una cosa que hay que consensuar antes de editar toda España sin
la información necesaria y tocando en algunos casos lo que ya hay. El
problema es que se ha empezado por zonas donde no había nada que romper. En
este caso ya intento hablar una persona con el de que era mejor hablarlo
primero. Y en vez de eso ha continuado hasta empezar a tocar zonas donde ya
hay información y se ha agravado el problema.

Ahora esta indicando verdy_p unas posibles soluciones a algunos de los
problemas aunque no ha todos, en el changeset. No sé si mejores o peores
pero que se podían hablar. El problema es que como el mismo ha indicado no
es el medio correcto para hacerlo. Y se le ha indicado varias maneras de
comunicarse con la comunidad.
https://www.openstreetmap.org/changeset/79639164

En vez de hablarlo con la comunidad parece que sigue editando.

Comenta problemas para entrar en la lista, pero problemas que creo que si se
quiere se pueden solucionar. Y también se le ha dado opción de usar otros
medios como Telegram y Matrix.

Yo no lo veo tan complicado hablar las cosas en vez de seguir erre que erre.
Espero que me lea esto, ya que se te ha vuelto a remitir a esta lista a este
hilo en particular. Las cosas se solucionan hablando y pido de nuevo que
hables con la comunidad por alguno de los diferentes medios pensados para
ello.

Saludos.



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk-fr] Les Data Items : discussion en cours

[Yves P.]

> Le 15 janv. 2020 à 21:50, Vincent Privat  a écrit :
> 
> Pour info, on vient tout juste d'intégrer Tag2link à JOSM core, et depuis les 
> règles peuvent être obtenues à partir de wikidata:
> https://josm.openstreetmap.de/ticket/18542#comment:6 
> 
Je viens de tester : ça fonctionne bien et c’est une grande avancée.

Petits bémols :
les expressions régulières ne sont pas (encore) prises en compte pour choisir 
le lien à générer (mais pas sûr que ça soit aussi le cas côté wikidata).
les identifiants composés faisant appel au « proxy » 
https://tools.wmflabs.org/wikidata-externalid-url affichent un lien vers tools… 
au lieu du site web de destination.

Ce dernier cas est dû à un « bidouillage » côté wikidata car l’URL formatter ne 
gère pas par défaut les expressions rationnelles.
On pourrait « améliorer » l’affichage et/ou éviter la redirection en 
interprétant les paramètres du lien (url=* et exp=*).
Exemple : https://www.wikidata.org/wiki/Property:P3563

Un grand merci avec développeurs de JOSM qui ont pris de le temps d’analyser et 
de code ça 

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

Re: [OSM-legal-talk] New data source

[Simon Poole]

I would suggest that you give a heads up on talk-gb in any case so that
other UK contributors know what's going on.

Simon

Am 18.01.2020 um 01:56 schrieb Cj Malone:
> Thanks Kathleen,
>
> I'll add attribution to the wiki tomorrow.
>
> My current intention isn't to automatically import, but rather
> generate a report where I can see where OSM names differ, then
> manually change the names is OSM via JOSM on a per node basis. Similar
> to https://gregrs.dev.openstreetmap.org/fhrs/ for food hygiene data.
>
> Based on my limited survey of differences in OSM data and SV data,
> theirs has been more accurate. Not really surprising, since it's there
> network, and most of the OSM data hasn't been updated since the naptan
> import nearly a decade ago.
>
> I don't think I will be making the report public, although since the
> data is not unique to the local bus operator, but rather their service
> providers. I could make reports for all areas available if desired.
> https://www.discoverpassenger.com/2019/06/25/open-data-portals-go-ahead-group/
>
> I don't really think this is an import, but rather "machine assisted"
> (if that's a thing in OSM vocabulary) I will however message the
> import mailing list to check there opinion on this. And I'll ask them
> if there is any point moving to the newer tagging method of
> public_transport=platform, as well as (for legacy reasons)
> highway=bus_stop.
>
> Thank you
>
> On 17 January 2020 21:28:16 GMT, Kathleen Lu via legal-talk
>  wrote:
>
> Hi Cj,
> Easiest method would be for you to update
> https://wiki.openstreetmap.org/wiki/Contributors with this
> information.
> (But please do note the import guidelines if you are thinking
> about importing)
> Best,
> Kathleen
>
> On Thu, Jan 16, 2020 at 5:26 AM Cj Malone  > wrote:
>
> Hello,
>
> I recently saw that some bus stop names are out of date in my
> area. I
> updated the one I saw (
> https://www.openstreetmap.org/node/533814248/history)
>
> But the local bus operator offers this data under Open Government
> License Version 3.0. (https://www.islandbuses.info/open-data)
>
> As far as I understand it OGL can be used in OSM, but needs
> attribution. Is this correct? How can OSM add the attribution
> so I can
> start using this dataset?
>
> Once someone verifies that I can use this dataset I intend to
> correct
> any OSM names, add fixme tags to any this I don't think exist
> any more.
> And possibly add naptan:AtcoCode=x to nodes that don't have it
> in OSM
> but do in the Southern Vectis dataset. And add
> "SouthernVectis" to the
> source tag which would usually mean, source=naptan_import ->
> source=naptan_import;SouthernVectis.
>
> Thanks
> Cj
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk


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

Re: [talk-au] Maxar bushfire imagery

[Sebastian S.]

I think the discussion regarding damaged is good, however I feel that this is a 
too fine grained quality for mapping from satellite images.

I would use ruined. Ruined can be fully destroyed or partially.

If damaged my next question would be how much? A little? Very subjective to 
quantify.



On 18 January 2020 9:34:58 am AEDT, Warin <61sundow...@gmail.com> wrote:
>On 17/1/20 10:08 pm, Mateusz Konieczny wrote:
>>
>>
>>
>> 17 Jan 2020, 11:42 by andrew.harv...@gmail.com:
>>
>> I'm all for using the lifecycle prefix,
>> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix. I agreed
>> that if there's still remains there use ruined or destroyed, not
>> sure what the difference is though.
>>
>> ruined implies that ruins still remain, destroyed may mean that or 
>> that there is no trace at all
>>
>> in practice difference is minor if any
>
>Most of these will still have foundations in place, they may not be fit
>
>for reuse but they are there. Some fire places and chimneys too remain.
>
>I'll use ruined. Unless there are other ideas?
>
>
>> Once it's been cleared you could use demolished, removed or
>raised
>>
>> Probably razed, not raised. I see not real difference.
>>
>> , again not sure what the difference is. While damaged is not
>> documented it seems the perfect fit since there is no other
>> suitable tag for this on the wiki.
>>
>> damaged seems to me a poor fit as prefix, damaged building is still a
>
>> building,
>> and I would expect building=something tag to be used.
>
>
>By damaged I mean part of the building is intact but another part has 
>been damaged .. e.g. a truck has run part way through the building.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

[pangose]

Hej
När det nu har lyfts så pass allvarlig kritik av importunderlaget så undrar jag 
om vi inte ska byta strategi och i stället sätta upp en server som via 
MapWithAI serverar datan per område för manuel bearbetning? 

Det skulle betyda att grigorys polerade data finns tillgängliga för alla med 
josm.
Då kringgår vi alla problem eftersom att det knappast behövs importeras nånting 
i Malmö, men mycket däremot saknas på Västernorrlands landsbygd och kan hämtas 
eftersom av nån med lokalkunskap.

Om jag förstått teknologin rätt så är den så smart att bara det som saknas i 
området som hämtas ind i mapwithai-lagret.

Mvh
pangoSE 

On January 18, 2020 12:03:27 AM GMT+01:00, Grigory Rechistov via Talk-se 
 wrote:
>
>Hej igen,
>Jag har uppdaterat mina skript för att upptäcka och slå samman
>ytterligare nodpar som borde vara en nod, t ex "Stora" + "mosse" ska
>till "Stora mosse" osv. Det fanns dock bara 5 (fem) noder att
>korrigera; de är nu taggade med ett extra nyckelvärde note="Name is
>merged from parts, recheck it".
> 
>Dessutom fick skripten och data mindre förbättringar att samtliga noder
>nu blir taggade med extra etiketter som dokumenterar vilka
>namnförändringar tillämpats av skriptet.
> 
>Länken till mappen results-v11: 
>https://drive.google.com/open?id=1SuAaC_uNJPzFb3lHquqDD3lQVWP_6iUu .
>Jag kommer även uppdatera importplanen men den feedback som redan
>finns.
> 
>Trevlig helg! Återkommer nästa vecka.
> 
> 
>Med vänliga hälsningar,
>Grigory Rechistov
>With best regards,
>Grigory Rechistov
> 
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

[Vincent Bergeot]

Le 18/01/2020 à 02:09, Shohreh a écrit :

Bonjour,

La requête suivante pour trouver tous les hôtels en France qui proposent une
prise pour recharger une voiture électrique… ne renvoie rien :

=
[out:json][timeout:60];

//France métrop : 1403916
rel(1403916);
map_to_area -> .searchArea;

(
   node[tourism=hotel][amenity=charging_station](area.searchArea);
   way[tourism=hotel][amenity=charging_station](area.searchArea);
);

out center;
=

Je m'y prends mal ou personne n'a taggé d'hôtels avec ça ?


Bonjour,

tu demandes dans la requête des objets qui ont les 2 tags, ce qui peut 
expliquer qu'il n'y en ait pas, l’hôtel et la prise étant 
vraisemblablement 2 objets différents (voir mail de Christian sur la 
borne de recharge dans le parking de l’hôtel).


Sur une emprise plus petite, et avec un rayon de 100 m, peut-être que 
cela peut commencer à donner une idée avec cette requête :


area[name="Cabourg"];
  node(area)[tourism=hotel]->.hotels;
  (
    way(around.hotels:100)[amenity=charging_station];
    node(around.hotels:100)[amenity=charging_station];
  );
  (._;>;);
  out meta;









Merci.



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

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



--
Vincent Bergeot


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

Re: [talk-cz] Podcast o Mapy.cz (i OSM)

[Matěj Cepl]

On 2020-01-17, 20:13 GMT, Pavel Zbytovský wrote:
> tip na něco k poslechu: rozhovor s Martinem Jeřábkem šéfem 
> Mapy.cz, asi 5 minut slávy dostalo i OpenStreetMap. Zmíněna 
> byla třeba dobrá spolupráce s komunitou. Zaujal mě ještě ve 
> výhledu plán na přidání možnosti editace přímo do Mapy.cz.

Zmiňují, že jsou schopni najít sjezdovku s osvětlením. Bohužel 
na https://wiki.openstreetmap.org/wiki/Tag:piste:type%3Ddownhill 
zjišťuji, že tam na to neexistuje ani nějaké klíčové slovo. Jak 
zavést diskusi na její zavedení?

Hezký den,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
 Don't come crying to me about your "30 minute
compiles"!! I have to build X uphill both ways! In the snow! With
bare feet! And we didn't have compilers! We had to translate the
C code to mnemonics OURSELVES!  And I was 18 before we even had
assemblers!


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

Re: [Talk-it] Corso di formazione OpenStreetMap per docenti (e non)

[Rossella Di Bari]

Buongiorno!
Io ne avrei proprio bisogno ma non sono docente. C'è un modo di bypassare
l'iscrizione da SOFIA?
Grazie :)

Rossella

Il ven 17 gen 2020, 08:06 Alessandro Sarretta 
ha scritto:

> Buongiorno,
> giro anche qui in lista la comunicazione che entro domani 18 gennaio è
> ancora possibile iscriversi al corso su OpenStreetMap che partirà il 25
> gennaio a Verona: https://www.wikimedia.it/formazione-docenti/modulo-c/
> È uno dei corsi di formazione docenti riconosciuti dal MIUR e
> organizzati da Wikimedia Italia:
> https://www.wikimedia.it/formazione-docenti/
> C'è la possibilità di frequentare il corso anche per non docenti; per
> maggiori informazioni:
> https://www.wikimedia.it/formazione-docenti/contatti/
> Se potete, fate rigirare tra i vostri contatti,
>
> Ale
>
>
> ___
> 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