Re: [talk-cz] Openstreetmap.cz + Fody: koňské rozcestníky

[Marián Kyral]

Chybí. U nás jsem ještě na žádný takový nenarazil. Máš návrh na nějakou
ikonku? Co třeba turistický a místo obdélníkové značky tam dát kolečka?




Marián




-- Původní e-mail --
Od: majkaz 
Komu: OpenStreetMap Czech Republic 
Datum: 20. 8. 2019 14:22:45
Předmět: [talk-cz] Openstreetmap.cz + Fody: koňské rozcestníky
"Nechybí nám ve Fody, resp. na openstreetmap.cz ikona koňského rozcestníku?
Pokud je to jen koňský rozcestník, ukazuje se u vyfocených jako "unknown.
png" - například https://osm.fit.vutbr.cz/fody/?id=22608

Nebo je tam ještě nějaká vada na kráse?

Majka

___
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

[OSM-ja] 位置参照情報（町丁目の階層づくり）について

[Satoshi IIDA]

いいだです。

農水省による筆ポリゴンもそうなのですが、並行して、国交省が公開している位置参照情報について、インポートができるかどうか検討を行っています。
いくつかの点について、議論と確認が必要かと思っています。

https://wiki.openstreetmap.org/wiki/JA:MLIT_ISJ

■1. 現状の位置参照情報の解説ページを更新します（やります）
URLで階層を作って、以下のようなイメージで更新します。
情報が欠損しないように気をつけますが、留意するべき点などあればコメントください。

* 位置参照情報自体についての説明
* インポート計画に関するページ
* インポート作業手順に関するページ

■2. タグの設定について（要議論）
これまで提案・利用されてきたデータの変換テーブルなのですが、ここに出てくるrefタグは不要なのではないか？と思っています。

理由1. quarterとneighbourhoodを分割する際に、新しく発生するquarterに対するrefを割り当てられない
理由2. このIDはこのデータセットの中でしか使われていないIDであり、他データとの連結に使えない

■3. 丁目、に対するタグの割当について（要議論）
これまでの議論では、タグを割り当てる際には以下の作業方針で作業を進めるようにしてきました。

大字：place=quarter
小字：place=neighbourhood
丁目：町名と丁目、を分割し、それぞれplace=quarterとplace=neighbourhoodとする。そのうえで、boundaryリレーションとしてsubareaとしてまとめあげる

ただ、先行してFacebookで議論をした限りでは、丁目のデータについて、町名と丁目、に分割しないほうがよいのではないか、という意見がでています。
（分割しない場合、place=neighbourhoodとして登録（？））
https://www.facebook.com/groups/osmjapan/permalink/2627157007336142/

理由1. XX町n丁目、が正式な名称である（ことが多い）
理由2. XX町YYn丁目、の表記を分割する際に、どこで区切りを入れるか不明瞭なケースがある（例:"志布志町"+"志布志一丁目" or
"志布志町志布志"+"一丁目"）

これを変更する場合、addressタグのスキーマについても運用を変更し、
丁目、の記述方法について修正を行う必要がある、と考えています。

https://docs.google.com/spreadsheets/d/1eAE72mjCLoJVGZo5qRhCYK22UxVQ8bpbQSU9ZLHq40o/edit#gid=0

幸か不幸か、日本におけるaddressタグの数はそこまで多いものではなく、
（iDエディタの実装など一部の混乱は予想されるものの）まだギリギリ、
既存データも正規化できる範囲ではないかとも考えています。
また、正規化しない場合でも、quarterとneighbourhoodをつなげて表現することで、利用に対応することも可能です。

■4. 丁目、の中の数字は、漢数字？（要議論）
位置参照情報のデータでは、数字は基本的に漢数字で表現されています。
正式名称が半角数字を使うケースや地域（特に、北海道の”条・丁目”表記）もあるようですが、インポート作業を行う際には、
漢数字そのままで作業をしてしまう、でもよいでしょうか。

半角数字が正式名称の場合は、別途作業として official_nameを使うなどで対応も可能かと思っています。


ご意見ありましたらよろしくお願いします。
（まずはwikiページ更新してから議論したほうがよいかしらん）


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-GB] OSNI Open Data

[Colin Smale]

Thanks Jerry, I had forgotten that NI comes under Ireland ;-) 

I will have a browse through the talk-ie archives and see if I can pick
it up there. 

Colin

On 2019-08-20 22:15, SK53 wrote:

> This query would actually be better directed at talk-ie as the Irish OSM 
> local chapter have been having discussions with OSNI (and OSI). 
> 
> However, I think it's safe to say that the relevant licence is not (yet) 
> compatible with OSM: I did briefly discuss this point with one of the Open 
> Data NI people who organised OpenData Camp #5 in Belfast, and she was 
> certainly of the view that OSNI data (or any LPS data) was not very open. 
> Many of these datasets would be very useful, for instance there is a point 
> data set of streetnames (e.g., when the name of this bit [1] of street was 
> being questioned, or just to do streetnames which are perhaps 10% completed). 
> 
> It is for this reason why there are no local authority boundaries in NI. 
> However, at some point I used FHRS data to produce concave hulls which would 
> be a first approximation (and no worse than things like the Limerick boundary 
> 3-4 years ago). Also KDDA has some open data for the old Fermanagh district  
> (on umap here [2]) which may assist in working out the boundaries (as will 
> townland and other boundaries). But do check with talk-ie before leaping in. 
> 
> At one point maps.openstreetmap.ie [3] had a number of overlay layers sourced 
> from the OSI/OSNI data, but I think these never got restored after the server 
> move. I used OSNI townland boundaries to compare with OSM ones back in 2015. 
> 
> Jerry 
> 
> On Tue, 20 Aug 2019 at 18:42, Colin Smale  wrote: 
> 
>> Has anyone investigated if the data covering Northern Ireland which OSNI 
>> make available under OGL V3, is licence-compatible with OSM in the same way 
>> as the OSGB open data? I am particularly interested in admin boundaries, 
>> e.g. 
>> http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2
>>  
>> 
>> The website says: "Open Government Data Licence applies.Land & Property 
>> Services (LPS) has made a number of Ordnance Survey of Northern Ireland(R) 
>> (OSNI(R)) branded datasets available free of charge under the terms of the 
>> current Open Government Licence (OGL). These datasets - which include raster 
>> and vector mapping, boundary, gazetteer, height, street and townland 
>> products - are available for download.  Each dataset is clearly marked with 
>> the OGL symbol. The OGL allows you to: copy, distribute and transmit the 
>> data; adapt the data; and exploit the data commercially, whether by 
>> sub-licensing it, combining it with other data, or including it in your own 
>> product or application. You are therefore able to use the LPS datasets in 
>> any way and for any purpose. We simply ask that you acknowledge the 
>> copyright and the source of the data by including the following attribution 
>> statement: Contains LPS Intellectual Property (c) Crown copyright and 
>> database right (year)  This information is
licensed under the terms of the Open Government Licence 
(http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3). You 
must also: include the same acknowledgement requirement in any sub-licences of 
the data that you grant, and a requirement that any further sub-licences do the 
same; ensure that you do not use the data in a way that suggests LPS endorses 
you or your use of the data; and make sure you do not misrepresent the data or 
its source. N.B. Any dataset that does not expressly state that it has been 
released under OGL will require a licence from LPS and the appropriate licence 
fee will be applied." 
>> 
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
--
[1] https://www.openstreetmap.org/way/392283077
[2]
https://umap.openstreetmap.fr/en/map/fermanagh-road-signs_290510#9/54.3614/-7.5142
[3] http://maps.openstreetmap.ie___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OSNI Open Data

[SK53]

This query would actually be better directed at talk-ie as the Irish OSM
local chapter have been having discussions with OSNI (and OSI).

However, I think it's safe to say that the relevant licence is not (yet)
compatible with OSM: I did briefly discuss this point with one of the Open
Data NI people who organised OpenData Camp #5 in Belfast, and she was
certainly of the view that OSNI data (or any LPS data) was not very open.
Many of these datasets would be very useful, for instance there is a point
data set of streetnames (e.g., when the name of this bit
 of street was being
questioned, or just to do streetnames which are perhaps 10% completed).

It is for this reason why there are no local authority boundaries in NI.
However, at some point I used FHRS data to produce concave hulls which
would be a first approximation (and no worse than things like the Limerick
boundary 3-4 years ago). Also KDDA has some open data for the old Fermanagh
district  (on umap here
)
which may assist in working out the boundaries (as will townland and other
boundaries). But do check with talk-ie before leaping in.

At one point maps.openstreetmap.ie had a number of overlay layers sourced
from the OSI/OSNI data, but I think these never got restored after the
server move. I used OSNI townland boundaries to compare with OSM ones back
in 2015.

Jerry

On Tue, 20 Aug 2019 at 18:42, Colin Smale  wrote:

> Has anyone investigated if the data covering Northern Ireland which OSNI
> make available under OGL V3, is licence-compatible with OSM in the same way
> as the OSGB open data? I am particularly interested in admin boundaries,
> e.g.
> http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2
>
> The website says: "Open Government Data Licence applies.Land &
> Property Services (LPS) has made a number of Ordnance Survey of Northern
> Ireland® (OSNI®) branded datasets available free of charge under the terms
> of the current Open Government Licence (OGL). These datasets – which
> include raster and vector mapping, boundary, gazetteer, height, street and
> townland products – are available for download.  Each dataset is clearly
> marked with the OGL symbol. The OGL allows you to: copy, distribute and
> transmit the data; adapt the data; and exploit the data commercially,
> whether by sub-licensing it, combining it with other data, or including it
> in your own product or application. You are therefore able to use the LPS
> datasets in any way and for any purpose. We simply ask that you acknowledge
> the copyright and the source of the data by including the following
> attribution statement: Contains LPS Intellectual Property © Crown copyright
> and database right (year)  This information is licensed under the terms of
> the Open Government Licence (
> http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3).
> You must also: include the same acknowledgement requirement in any
> sub-licences of the data that you grant, and a requirement that any further
> sub-licences do the same; ensure that you do not use the data in a way that
> suggests LPS endorses you or your use of the data; and make sure you do not
> misrepresent the data or its source. N.B. Any dataset that does not
> expressly state that it has been released under OGL will require a licence
> from LPS and the appropriate licence fee will be applied."
>
>
>
> ___
> 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-be] hidden official path vs. unofficial by-pass : consensus?

[Francois Gerin]

Hi,

Here is a probably subjective issue, that has certainly already been 
discussed, but I cant' find a search engine for the mailing archives.


Problem:
It's very frequent, in Belgium and certainly in many places, that a 
private or farmer steals a footway because he dislikes people pass there 
or just to extend his field for free.
The **official** path is then often no more visible and, sometime, there 
may have an **unofficial** by-pass in the area.

The official trace MUST be kept because, well... it is official. :-)
And also because the by-pass MAY disappear at any time.

Envisioned solutions:
1. Keep official path only.  =bad because it does not reflect the 
reality (which may stand for many years!)
2. Delete the official one, draw the by-pass. =rejected, because the 
official must be kept, or we may loose both
3. Keep both, but flag the hidden one with trail_visibility tag. =best 
option found up to now, which seems accepted widely+officially


Questions:
A. Is there any OSM consensus for a solution, at the global/worldwide 
community level?

B. If not, is there any Belgian community consensus?
C. If not, is there any widely accepted option?
D. If not, is there any better solution than option 3?

(Side issue: the current rendering on OSM does not express that this 
path is poorly visible. But at least the flag is there for other 
rendering tools/layouts.)


Two examples I had to do:
https://www.openstreetmap.org/way/700172645
https://www.openstreetmap.org/way/629096505

Thank you in advance for any pointer/doc/wiki/consensus! :-)

Regards,
François
(aka fgerin on OSM)
(aka fge1 on balnam)


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

Re: [Talk-it] allevamenti di polli

[Paola via Talk-it]

Grazie Lorenzo,

chiarissimo!

Paola

> Il 20 agosto 2019 alle 17.20 Lorenzo Beltrami  ha 
> scritto:
> 
> Il giorno mar 20 ago 2019 alle ore 16:31 Paola via Talk-it < 
> talk-it@openstreetmap.org mailto:talk-it@openstreetmap.org > ha scritto:
> 
> > > [...]
> > quale potrebbe essere il più corretto o quali modifiche fare, 
> > pensando di utilizzarlo non solo per il pollame ma anche per altre specie? 
> > (vacche, cavalli, capre, suini...)?
> > Grazie
> > 
> > > 
> Io farei così:
> 
> 1. Sull'area di tutta la fattoria:
> landuse=farmyard (che indica la fattoria)
> amenity=animal_breeding (che indica l'allevamento che viene svolto nella 
> fattoria)
> animal_breeding=chicken;goose (come esempio ho messo galline e oche)
> produce=meat (che indica animali da carne)
> Ad esempio: https://www.openstreetmap.org/way/715688642
> 
> 2. All'interno della fattoria di cui al punto 1., per ogni singolo 
> edificio in cui sta il pollame:
> building=poultry_house (indica che la struttura di quell'edificio è fatta 
> per il pollame)
> livestock=chicken per un edificio che contiene solo galline
> livestock=goose per un edificio che contiene solo oche
> 
> Opzionale. Sempre all'interno della fattoria di cui al punto 1. per 
> l'edificio dove abita l'allevatore:
> building=farm (se si tratta di una tipica casa di campagna) o 
> bulding=house (se si tratta di una normale casa indipentente)
> 
> Mi sembra che lo stesso schema si possa replicare un po' per tutti i tipi 
> di animali con le dovute accortezze (cioè che se ho delle mucche al punto 2. 
> avrò dei buliding=cow_shed, se ho dei maiali al punto 2. avrò dei 
> buildign=sty, ecc.)
> 
> Spero di essermi spiegato :-p
> 
> Lorenzo
> 



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

Re: [Talk-lv] don gastronom/españa

[Mārtiņš Bruņenieks]

Varbūt https://wiki.openstreetmap.org/wiki/Tag:shop%3Ddeli

Rihards  (šajā datumā: Ot, 2019. g. 20. aug. 20:29)
rakstīja:

> Kādu veikala tagu vislabāk būtu likt Don Gastronom/España veikaliem?
>
> http://www.dongastronom.lv/lv/stores
> --
>  Rihards
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv

[Talk-GB] OSNI Open Data

[Colin Smale]

Has anyone investigated if the data covering Northern Ireland which OSNI
make available under OGL V3, is licence-compatible with OSM in the same
way as the OSGB open data? I am particularly interested in admin
boundaries, e.g.
http://osni-spatial-ni.opendata.arcgis.com/datasets/a55726475f1b460c927d1816ffde6c72_2


The website says: "Open Government Data Licence applies.Land &
Property Services (LPS) has made a number of Ordnance Survey of Northern
Ireland(R) (OSNI(R)) branded datasets available free of charge under the
terms of the current Open Government Licence (OGL). These datasets -
which include raster and vector mapping, boundary, gazetteer, height,
street and townland products - are available for download.  Each dataset
is clearly marked with the OGL symbol. The OGL allows you to: copy,
distribute and transmit the data; adapt the data; and exploit the data
commercially, whether by sub-licensing it, combining it with other data,
or including it in your own product or application. You are therefore
able to use the LPS datasets in any way and for any purpose. We simply
ask that you acknowledge the copyright and the source of the data by
including the following attribution statement: Contains LPS Intellectual
Property (c) Crown copyright and database right (year)  This information
is licensed under the terms of the Open Government Licence
(http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3).
You must also: include the same acknowledgement requirement in any
sub-licences of the data that you grant, and a requirement that any
further sub-licences do the same; ensure that you do not use the data in
a way that suggests LPS endorses you or your use of the data; and make
sure you do not misrepresent the data or its source. N.B. Any dataset
that does not expressly state that it has been released under OGL will
require a licence from LPS and the appropriate licence fee will be
applied."___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-lv] don gastronom/españa

[Rihards]

Kādu veikala tagu vislabāk būtu likt Don Gastronom/España veikaliem?

http://www.dongastronom.lv/lv/stores
-- 
 Rihards

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

Re: [Talk-de] Idee zum einfachen Baum Mapppen unterwegs?

[Volker Schmidt]

Mit so vielen guten Mapillary-Bildern kannst du doch das ganze auf den
Winter vertagen und Mapllary-Bilder plus Satelliten-Fotos auswerten und
hinter-dem-Ofen mappen (noch besser als armchair mapping!). Und wenn das
Wetter jetzt schoen ist, statt mit dem GPS jeden einzelnan Baum einmessen,
setz dich aufs Fahrrad und fotografier noch den Rest fuer Mapillary. Dann
hast du fuer den ganzen Winter ausgesorgt und langweilst dich nicht..

Scherz beiseite, aber das Material das du da hast ist so gut, dass du da
hemmungslos armchair mapping machen kannst..

Gruss

Volker

On Tue, 20 Aug 2019 at 14:19, Lars Schimmer 
wrote:

> Hallo!
>
> Ich habe demnächst 1,2 Tage Zeit in meiner Heimatgegend ein paar
> Obstbäume in der Feldmarkt zu mappen.
>
> Hat wer Tips, wie ich am einfachsten unterwegs am Mobilgerät Nodes
> setzen kann mit einem vorgefertigtem Tagset?
>
> Sprich: Handy ist an, ich gehe zum Baum, drück auf die (stark gezoomte)
> Karte (oder Knopf), App setzt einen Node an dem Punkt nach GPS/Karte und
> zeigt mir ein Tagset aus, idealerweise das vom Node vorher, in diesem
> Falle trees=apple oder ähnliches.
>
> Ich mag einfach ned aus mapillary alle Bäume manuell in die Karte
> klicken und taggen.
>
> Danke.
>
> ( z.B.:
>
> https://www.mapillary.com/app/?lat=52.13998643270335=10.065918396861543=17=W4taLJSLgdk_-zbnLmYSCw=photo
> oder
>
> https://www.mapillary.com/app/?lat=52.14205438532002=10.058797920427423=17=Imrrhgn62962o0DaQKd8bQ=photo
> )
>
> MfG,
> Lars Schimmer
> --
> -
> TU Graz, Institut für ComputerGraphik & WissensVisualisierung
> Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
> Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Sur rendez-vous

[osm . sanspourriel]

Pourquoi utiliser la même clé pour "pourrir" la valeur alors qu'une clé
dédiée existe ?

Pourrir au sens qu'il s'agit d'une annotation _qui ne sera pas traitée_
par les programmes utilisant opening_hours.

De plus les commentaires doivent être dans la langue parlée dans la
région donc exit les "reservation only" comme précisé en fin de texte de
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification.

Je sais bien que mon cabinet de médecin a, en été, un horaire de
réservation qui diffère des horaires de travail des médecins.

Mais si tu vas par là, les jours de travail des médecins diffèrent
(travail le mercredi /ou/ le samedi).

reversation=required est bien ce qu'il faut.

Et tu mets dans opening_hours les heures du secrétariat.

Si les gens obtiennent un rendez-vous en dehors des horaires du
secrétariat, crois-moi, ils viendront même si selon OSM le cabinet est
fermé ;-).

Sinon tu mets un amenity=reception_desk avec les horaires du secrétariat
mais je ne vois pas comment tu vas lier les amenity=doctors avec.

Ceci dit "reversation=required", "/"/reservation only/" /n'est pas
strictement exact : en cas d'urgence un médecin te recevra et les
suivant qui ont réservé passeront après.

C'est comme quand tu as un examen programmé aux urgences : en cas
d'urgence ton examen sera retardé.

> /09:00-12:00 open "/reservation only/", 14:00-19:00 open "public room"/

Là je ne comprends pas ce que tu veux dire. Que tu ne peux aller le
matin que sur RdV et l'après-midi c'est sans RdV ?
Si je reprends mon cabinet médical les demies-journées sans RdV
diffèrent selon les jours.
Initialement 4 médecins, 3 salles. Donc ça foire.
revervation=optional n'est pas prévu (pour le moment).

Je pense que tu a voulu dire 09:00-12:00 open "sur réservation",
14:00-19:00 open "sans réservation"
Ou est-ce 09:00-12:00 open "réservation, consultations", 14:00-19:00
open "consultations sans réservation" ?

> On parle pas là d'horaire pendant lesquels on peut appeler pour réserver
Ce n'est pas ce que demandait Jacques :
> Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
>> je ne sais pas indiquer que voir la dentiste est uniquement « sur
rendez-vous »
Et là aussi, si tu as une un gros problème, la dentiste va t'accepter
entre deux rendez-vous. A mimina pour te donner un remède de cheval le
temps d'attendre un rendez-vous.

Jean-Yvon

Le 20/08/2019 à 14:31, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] Import von BEV Adress- Stichtagsdaten Österreich

[Johann Haag]

Grundsätzlich sollte man einen Neuantrag keinesfalls mit gescheiterten
Versuchen der Vergangenheit vermischen, sondern sich auf das
gegenständliche konzentrieren.
Die von ScubbX verlinkte Entlastung von OSM Mitwirkenden (was sehr wichtig
ist), bezieht sich nicht auf unsere moralische Verantwortung, etwas mit
OpenStreetMap begonnenes, auch zu Ende zu führen.

OpenStreetMap Österreich steht in Adressen heute ungefähr in der Mitte
eines Prozesses, wir haben nun gesellschaftliche Unterstützung durch
gesetzliche OpenData Initiativen erhalten, wir können uns solcher
Unterstützung nicht verschließen, ohne moralisch hierbei ins Dilemma zu
kommen.

https://wiki.openstreetmap.org/wiki/WikiProject_Austria/%C3%96sterreichisches_Adressregister


Was die Technik anbelangt, bei einem Autokauf nutzt man vorhandene
Technologien, im Jahr 2019 konzentriert man sich auf die Definition der
eigenen Bedürfnisse. Programmieraufwand kann man, sofern die eigene
Expertise nicht vorliegt, anschließend problemlos auslagern.
Grüße Johan Haag St. Johann in Tirol

Am Di., 20. Aug. 2019 um 00:24 Uhr schrieb scubbx :

> Hallo, Johann!
>
> Bevor ich weder dafür noch gegen einen Import sein kann, möchte ich mehr
> über deine geplante Abgleichsmethode zu bestehenden Adressdaten in der
> OpenStreetMap erfahren.
> Das ist sicherlich keine einfache Sache, da der freie BEV Datensatz ja
> zwei unterschiedliche Adressdatensätze mit unterschiedlicher Verortung
> beinhält und halbjährliche aktualisiert wird. Auch sind Probeanalysen aus
> Testregionen notwendig um die Tauglichkeit des BEV Adressdatensatzes für
> die OSM zu überprüfen.
> Mit etwas Programmierkenntniss gibt es aber bestimmt eine Lösung - wenn
> auch keine triviale.
>
> Eine Anwendungswarnung ist überflüssig, da solch eine bereits durch die
> Contributor Terms und die OpenDatabaseLicence gegeben ist. ( §8 der ODbL
> 1.0 https://opendatacommons.org/licenses/odbl/1.0/index.html für die
> "Warnung" und §7 der CT
> https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms/DE für
> Verantwortung)
>
> Ich muss zugeben, dass ich nach den letzten Ereignissen an deiner Stelle
> dieses wunde Thema etwas verheilen lassen würde.
>
> Beste Grüße,
> Markus (ScubbX)
> Am 19.08.19 um 08:12 schrieb Johann Haag:
>
> Ich habe vor in folgende Tabelle
> https://wiki.openstreetmap.org/wiki/Import/Catalogue  den Import der uns
> vom BEV in geeigneter Lizenz zur Verfügung gestellten Adressen (BEV
> Stichtagsdaten) einzutragen. Bitte um Diskussion.
>
> Begründung: OpenStreetMap Adressen werden heute von einer Vielzahl an
> Applikationen genutzt. OpenStreetMap steht daher in gesellschaftlichen
> Verantwortung, den jeweiligen Datenzustand der Adresserfassung öffentlich
> klar zu transportieren. Derzeit ist wohl noch eine Anwendungswarnung von
> Adressen auszusprechen (Blaulicht Problem). Ref:
> https://lists.openstreetmap.org/pipermail/talk-at/2019-August/010172.html
> Grüße Johann
>
> ___
> Talk-at mailing 
> listTalk-at@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-at
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] allevamenti di polli

[Lorenzo Beltrami]

Il giorno mar 20 ago 2019 alle ore 16:31 Paola via Talk-it <
talk-it@openstreetmap.org> ha scritto:

> [...]
> quale potrebbe essere il più corretto o quali modifiche fare, pensando di
> utilizzarlo non solo per il pollame ma anche per altre specie? (vacche,
> cavalli, capre, suini...)?
> Grazie
>

Io farei così:

1. Sull'area di tutta la fattoria:
landuse=farmyard (che indica la fattoria)
amenity=animal_breeding (che indica l'allevamento che viene svolto nella
fattoria)
animal_breeding=chicken;goose (come esempio ho messo galline e oche)
produce=meat (che indica animali da carne)
Ad esempio: https://www.openstreetmap.org/way/715688642

2. All'interno della fattoria di cui al punto 1., per ogni singolo edificio
in cui sta il pollame:
building=poultry_house (indica che la struttura di quell'edificio è fatta
per il pollame)
livestock=chicken per un edificio che contiene solo galline
livestock=goose per un edificio che contiene solo oche

Opzionale. Sempre all'interno della fattoria di cui al punto 1. per
l'edificio dove abita l'allevatore:
building=farm (se si tratta di una tipica casa di campagna) o bulding=house
(se si tratta di una normale casa indipentente)

Mi sembra che lo stesso schema si possa replicare un po' per tutti i tipi
di animali con le dovute accortezze (cioè che se ho delle mucche al punto
2. avrò dei buliding=cow_shed, se ho dei maiali al punto 2. avrò dei
buildign=sty, ecc.)

Spero di essermi spiegato :-p

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

[Talk-us] HOT Summit and State of the Map

[Tyler Radford]

Hi all,
Really looking forward to connecting and re-connecting at State of the Map
US in Minneapolis and/or State of the Map in Heidelberg, Germany.

In case you were not already aware, Humanitarian OpenStreetMap Team will
hold our annual Summit in the two days immediately preceding State of the
Map in Germany in the same venue.

https://summit2019.hotosm.org/

All are welcome and hope you can come to Germany a few days early to
participate. Best
Tyler

*Tyler Radford*
Executive Director
tyler.radf...@hotosm.org
@TylerSRadford

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | facebook
 | donate 
[image:
https://docs.google.com/uc?export=download=1kKgEK5TO0KEOP05FlhGVUzP9F4P0us5J=0Bwm-l_34V77faU9pcFdyYVFNRWtUZnBIWVNPYjF0TDhTY2JJPQ]

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

Re: [Talk-it] allevamenti di polli

[Martin Koppenhoefer]

sent from a phone

> On 20. Aug 2019, at 16:30, bonatopa...@libero.it wrote:
> 
> quale potrebbe essere il più corretto


direi nessuno dei due: è poco probabile che landuse e building sullo stesso 
oggetto siano corretti (soprattutto in campagna). L’oggetto landuse comprende 
tutta l’area (anche non edificata, eventualmente anche con più edifici).

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

Re: [Talk-it] allevamenti di polli

[Paola via Talk-it]

Grazie a tutti,
utilizzando taginfo e overpass turbo non ho trovato un modo "simile" per 
indicare i vari allevamenti di polli piuttosto che di suini o polli...
In base alle indicazioni che mi avete dato pensavo di utilizzare i seguenti tag:
ad esempio per un allevamento di polli:

opz1
building=poultry_house
landuse=farmyard
amenity=animal_breeding
animal_breeding=poultry;
produce=meat

opz 2
building=poultry_house
landuse=farmyard
amenity=animal_breeding
livestock=poultry
poultry=chicken
produce=meat

quale potrebbe essere il più corretto o quali modifiche fare, pensando di 
utilizzarlo non solo per il pollame ma anche per altre specie? (vacche, 
cavalli, capre, suini...)?
Grazie



> Il 20 agosto 2019 alle 15.37 Martin Koppenhoefer  ha 
> scritto:
> 
> 
> 
> sent from a phone
> 
> On 20. Aug 2019, at 08:57, Lorenzo Beltrami < lorenzo.b...@gmail.com 
> mailto:lorenzo.b...@gmail.com > wrote:
> 
> 
> > > livestock=* è una chiave che non ho trovata documentata 
> sulla wiki, quindi non saprei dirti di preciso per cosa viene usata... Così 
> su due piedi direi che indica il tipo di bestiame presente in un dato elemento
> > 
> > > 
> +1
> se ne parla attualmente in lista di tagging con lo scopo di creare una 
> voce di documentazione, da qui in poi:
> https://lists.openstreetmap.org/pipermail/tagging/2019-August/047500.html
> 
> Ciao Martin 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 



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

Re: [OSM-talk-fr] Sotm Heidelberg : on y va ensemble ?

[Frédéric Rodrigo]

Bonjour,

Je pense qu'il est temps de s'organiser pour le sotm !

Pour l'instant il y a 18 personnes sur la liste et toutes sont partant 
pour partager un logement.
Il était posé la question d'une participation éventuelle de l'asso aux 
frais. C'est la cas ?


Le choix de logements pour beaucoup de monde à Heidelberg sur AirBnb est 
assez limité.

https://www.airbnb.fr/s/Heidelberg--Allemagne/homes?refinement_paths%5B%5D=%2Fhomes=Heidelberg%2C%20Allemagne_type=filter_change_lat=49.44515996013923_lng=8.749412080078173_lat=49.3505351128317_lng=8.58393051269536=13_by_map=true_id=ChIJzdzMDgXBl0cR1zokRADq5u8=2019-09-20=2019-09-24=10_tag=1IQRYSb2


De mon coté il faut que je commence à m'organiser.
Je peut participer à un covoiture partant de Paris, et faire un 
Bordeaux-Paris en train. Pas de retour à prévoir pour moi.


Frédéric.



Le 28/06/2019 à 08:48, PanierAvide a écrit :

Bonjour,

Petite relance : n'oubliez pas de remplir le tableau dont le lien est 
ci-dessous si vous vous rendez au State of the Map d'Heidelberg pour 
que l'on trouve le meilleur coup de pouce que l'asso peut offrir ;-)


Cordialement,

Adrien P.

Le 17/06/2019 à 14:51, PanierAvide a écrit :

Bonjour à tous,

Le State of the Map mondial se déroule cette année à Heidelberg, 
ville allemande assez proche de nos frontières. L'association OSM 
France souhaite ainsi faciliter la venue de contributeurs français à 
l'évènement. Plusieurs idées ont été émises pour y parvenir :


- Partager le transport depuis Paris pour converger vers Heidelberg
- Partager un hébergement sur place pour réduire les frais
- Prendre en charge les frais de transport/hébergement de contributeurs

Afin que nous puissions trouver les solutions répondant au mieux aux 
attentes, j'ai ouvert un tableur partagé où vous pouvez indiquer si 
vous prévoyez de vous rendre à l'évènement, et quels aspects vous 
intéresseraient pour faciliter votre venue :


https://lite.framacalc.org/orga_fr_sotm_heidelberg

Je vous laisse y ajouter vos infos le plus rapidement possible (avant 
la fin du mois) pour que nous puissions ensuite vous proposer une 
offre mutualisée ou prise en charge dans la mesure du possible :-)


Cordialement.



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




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

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[marc marc]

la relation Bourgogne-Franche-Comté est, selon osm composé de
l'Académie de Dijon, zone A
l'Académie de Besançon, zone A
ca me semble donc tout a fait réaliste de TESTER l'ajout du SH zone A 
sur la relation Bourgogne-Franche-Comté

Le 20.08.19 à 12:43, Christian Quest a écrit :
> Le hic, c'est que les zones A/B/C sont liées aux académies et pas aux 
> régions... et je ne sais pas si elles ne chevauchent pas des régions...
> 
> Le mar. 20 août 2019 à 11:19, marc marc  > a écrit :
> 
> Bonjour,
> 
> j'aurais tendance à commencer en testant l'ajout du SH sur
> la relation Bourgogne-Franche-Comté, l'outil ayant l'air de
> dire qu'il le prendrait en compte.
> cela permettrait de vérifier qu'il n'y a pas d'autre problème
> avant d'ouvrir un ticket sur l'outil et/ou d'en parler
> sur tagging pour voir comment faire "harmonisé"
> 
> Cordialement,
> Marc
> 
> Le 16.08.19 à 15:54, Yves P. a écrit :
>  > J'ai essayé la syntaxe suivante pour ce musée :
>  > Jul-Aug 10:30-18:30; May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa
>  > 13:30-18:00; SH Tu-Sa 13:30-18:00
>  >
>  > Le script renvoi l'erreur suivante :
>  > An error occurred during evaluation of the value "Jul-Aug
> 10:30-18:30;
>  > May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa 13:30-18:00; SH Tu-Sa
>  > 13:30-18:00". Please submit a pull request:
>  > https://github.com/opening-hours/opening_hours.js. There are no
> holidays
>  > (SH) defined for country fr and state Bourgogne-Franche-Comté.
>  >
>  > __
>  > Yves
>  >
>  > https://openingh.openstreetmap.de/evaluation_tool/
>  >
>  >
>  >
>  >
>  > Le ven. 16 août 2019 à 15:50, Yves P.  
>  > >>
> a écrit :
>  >
>  >     Bonjour,
>  >
>  >     La syntaxe existe ("SH") mais il n' y a pas de définition
> pour les
>  >     vacances solaires en France :
>  >
> 
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/fr.yaml
>  >
>  >     Comment définir les zones ?
>  >     opening-hours ne semble utiliser que les régions (cf. README.md
>  >   
>   
> )
>  >
>  >     Il existe dans OSM des relations pour les zones scolaires :
>  >
>  >       * France, vacances scolaires, zone A
>  >         
>  >       * France, vacances scolaires, zone B
>  >         
>  >       * France, vacances scolaires, zone C
>  >         
>  >
>  >     Il faut probablement soumettre une /"issue"/ dans
> opening_hours pour
>  >     que le script gère directement ces relations et/ou les tags
>  >     *holiday_zone* des relations *boundary educational.*
>  >     *
>  >     *
>  >     Et/ou aussi étendre la syntaxe *SH* en spécifiant une zone ?
>  >     SH A,C // vacances scolaires zone A et C
>  >
>  >     J'ai un musée qui à des horaires d'ouvertures spécifiques
> pour les
>  >     vacances scolaires quelque soit la zone :
>  > https://www.atelierdessavoirfaire.fr/
>  >
>  >     En attendant, peut-on définir des vacances comme "Vacances
> xxx zone Y" ?
>  >
>  >     Exemple : Vacances d'hiver zone A
>  > https://www.education.gouv.fr/pid25058/le-calendrier-scolaire.html
>  >
>  >     Fin des cours :
>  >     samedi 22 février 2020
>  >     Reprise des cours :
>  >     lundi 9 mars 202
>  >
>  >        SH:
>  >          - name: Vacances d'hiver zone A
>  >            '2020': [2, 23, 3, 8]
>  >
>  >     Fichier pour l'Allemagne (contient des définitions pour les
> vacances
>  >     scolaires)
>  >
> 
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/de.yaml
>  >
>  >     __
>  >     Yves
>  >     **
>  >
>  >
>  > ___
>  > Talk-fr mailing list
>  > Talk-fr@openstreetmap.org 
>  > https://lists.openstreetmap.org/listinfo/talk-fr
>  >
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [Talk-it] boundary=region

[Lorenzo Beltrami]

Il giorno mar 20 ago 2019 alle ore 14:41 emmexx  ha
scritto:

> Mi sono casualmente imbattuto in questa relazione:
>
> https://www.openstreetmap.org/relation/2698607#map=7/46.006/10.818
>
> In una parte di territorio che conosco si tratta di un confine
> approssimato, anche perché non saprei come definire chiaramente le Alpi.
>
> A cosa serve una relazione come questa se non per rendering o per gli
> scopi di qualche specifico consumatore di dati?
>

boundary=region non l'ho mai sentita, su TagInfo c'è solo 355 volte e su
OSM Tag History sembra che la maggior parte delle occorrenze sia dovuta ad
un import.

Secondo me di quella relazione lì la cosa più importante è
natural=moutain_range[0]. Anche se, come hai giustamente notato tu, ha poco
senso rappresentarla come un'area. Infatti sulla wiki dice di usare un nodo
o una linea.

Su OSM Deep  History si comprende un po' meglio l'evoluzione:
https://osmlab.github.io/osm-deep-history/#/relation/2698607
È stato creata proprio come natural=mountain_range dal nostro scratera nel
2013 (poi c'è stata una breve parentesi come parcheggio e una come area
pedonale, più altri vari errori xD) finché non è stata trasformata da
multipolygon a boundary da woodpeck nel 2017[1], riportata a
multipolygon[2] e infine, sempre da woodpeck, ripristinata in boundary[3]
spiegando di non usare i multiploygon per regioni così vaste.

Lorenzo

[0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dmountain_range
[1] https://www.openstreetmap.org/changeset/48328235
[2] https://www.openstreetmap.org/changeset/51612403
[3] https://www.openstreetmap.org/changeset/62005421
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] allevamenti di polli

[Martin Koppenhoefer]

sent from a phone

> On 20. Aug 2019, at 08:57, Lorenzo Beltrami  wrote:
> 
> livestock=* è una chiave che non ho trovata documentata sulla wiki, quindi 
> non saprei dirti di preciso per cosa viene usata... Così su due piedi direi 
> che indica il tipo di bestiame presente in un dato elemento


+1
se ne parla attualmente in lista di tagging con lo scopo di creare una voce di 
documentazione, da qui in poi:
https://lists.openstreetmap.org/pipermail/tagging/2019-August/047500.html

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

Re: [Talk-it] boundary=region

[liste DOT girarsi AT posteo DOT eu]

Il 20/08/19 15:13, liste DOT girarsi AT posteo DOT eu ha scritto:
> Da quanto vedo sul suo profilo è iscritto da luglio, inoltre tutti i
> suoi interventi sono piccoli, tra Slovenia e Ungheria, ho idea che la
> relazione sia stata toccata per sbaglio.
> 
> https://www.openstreetmap.org/user/Filip%20Kokol/history#map=8/46.254/17.037
> 
> 
> 

Guardando le modifiche a questo changeset, ha aggiunto un tratto di
ciclabile, e probabile abbia toccato la relazione che probabile passa
per di lì:

https://overpass-api.de/achavi/?changeset=73301542


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

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

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Jérôme Seigneuret]

@Yves si il est ouvert quelque soit la zone ça sert à rien de le mentionner
vu qu'il est ouvert de base

Le mar. 20 août 2019 à 15:07, Yves P.  a écrit :

>
>
> Le mar. 20 août 2019 à 14:12, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>>
>> La partie SH se suffit à elle même c'est comme quand on parle des jours
>> férié.
>>
> ??
>
>
>> Concernant les commerces je vais juste une question qui me trotte.
>> As-t-on des commerces/services qui seraient ouverts ou fermés mais sur la
>> zone d'une autre académie?
>>
> Au moins un, le musée cité dans mes 2 premiers messages.
> Il est ouvert quelque soit la zone.
>
> --
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] boundary=region

[liste DOT girarsi AT posteo DOT eu]

Il 20/08/19 14:40, emmexx ha scritto:
> Mi sono casualmente imbattuto in questa relazione:
> 
> https://www.openstreetmap.org/relation/2698607#map=7/46.006/10.818
> 
> In una parte di territorio che conosco si tratta di un confine
> approssimato, anche perché non saprei come definire chiaramente le Alpi.
> 
> A cosa serve una relazione come questa se non per rendering o per gli
> scopi di qualche specifico consumatore di dati?
> 
>   maxx

Da quanto vedo sul suo profilo è iscritto da luglio, inoltre tutti i
suoi interventi sono piccoli, tra Slovenia e Ungheria, ho idea che la
relazione sia stata toccata per sbaglio.

https://www.openstreetmap.org/user/Filip%20Kokol/history#map=8/46.254/17.037



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

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

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Yves P.]

Le mar. 20 août 2019 à 14:12, Jérôme Seigneuret 
a écrit :

>
> La partie SH se suffit à elle même c'est comme quand on parle des jours
> férié.
>
??


> Concernant les commerces je vais juste une question qui me trotte. As-t-on
> des commerces/services qui seraient ouverts ou fermés mais sur la zone
> d'une autre académie?
>
Au moins un, le musée cité dans mes 2 premiers messages.
Il est ouvert quelque soit la zone.

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

[Talk-it] boundary=region

[emmexx]

Mi sono casualmente imbattuto in questa relazione:

https://www.openstreetmap.org/relation/2698607#map=7/46.006/10.818

In una parte di territorio che conosco si tratta di un confine
approssimato, anche perché non saprei come definire chiaramente le Alpi.

A cosa serve una relazione come questa se non per rendering o per gli
scopi di qualche specifico consumatore di dati?

maxx

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

Re: [OSM-talk-fr] Sur rendez-vous

[Jérôme Seigneuret]

Bonjour,
On est sur de la réservation pendant les horaires d'ouvertures. Pourquoi
voudrais-tu utiliser une autre clé? En soit c'est la bonne clé.
Si on veut gérer des horaires globaux d'ouvertures on le met avec un
contexte
*09:00-12:00 open "*reservation only*", 14:00-19:00 open "public room"*


booking c'est forcément de la réservation hors c'est pas le cas pour les
médecins. On parle pas là d'horaire pendant lesquels on peut appeler pour
réserver. De plus certains médecins ne prennent même plus le temps de
répondre au téléphone pour les réservations. C'est un répondeur qui demande
d'utiliser une plateforme de réservation en ligne.

et encore on pourrait utiliser  *09:00-11:00 "call us for reservation"*

Jérôme

Le mar. 20 août 2019 à 12:39, Topographe Fou  a
écrit :

> Bonjour,
>
> Il vaut mieux à mon sens éviter d'utiliser le champ opening_hours pour
> cela, sinon on en arrive à mélanger la maintenance des horaires avec celle
> des multiples possibilités de réservation (téléphone mais aussi Internet,
> sur place...). En plus le standard n'a pas forcément les mêmes horaires que
> les consultations. Idem pour Internet (24/7). La proposition de Marc est
> préférable à mes yeux : mettre la réservation sur un tag dédié (voir aussi
> la direction qui avait eu lieu en juin je crois sur la réservation
> hôtelière avec le débat booking=*) et laisser les horaires d'ouverture pour
> les horaires d'ouverture.
>
> C'est bien différent d'un magasin qui n'ouvrirait que sur rendez-vous
> (sens de l'usage dans opening_hours).
>
> Cordialement,
>
> LeTopographeFou
>
>
>   Message original
>
>
>
> De: marc_marc_...@hotmail.com
> Envoyé: 20 août 2019 9:41 AM
> À: talk-fr@openstreetmap.org
> Répondre à: talk-fr@openstreetmap.org
> Objet: Re: [OSM-talk-fr] Sur rendez-vous
>
>
> Bonjour
>
> Le 19.08.19 à 18:52, David Crochet a écrit :
> > Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
> >> je ne sais pas indiquer que voir la dentiste est uniquement « sur
> >> rendez-vous »
> >
> > *opening_hours=xx:xx* |"||reservation by phone"|
> >
> > en remplacant xx:xx par les jours/horaires d'ouverture
>
> il y aussi reservation=required
> https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation
>
> Cordialement,
> Marc
> ___
> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Jacques Lavignotte]

Le 20/08/2019 à 12:43, Christian Quest a écrit :
Le hic, c'est que les zones A/B/C sont liées aux académies et pas aux 
régions...


Je crois que ça va pas durer... :(


--
GnuPg : C8F5B1E3 Because privacy matters.


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

[Talk-de] Idee zum einfachen Baum Mapppen unterwegs?

[Lars Schimmer]

Hallo!

Ich habe demnächst 1,2 Tage Zeit in meiner Heimatgegend ein paar
Obstbäume in der Feldmarkt zu mappen.

Hat wer Tips, wie ich am einfachsten unterwegs am Mobilgerät Nodes
setzen kann mit einem vorgefertigtem Tagset?

Sprich: Handy ist an, ich gehe zum Baum, drück auf die (stark gezoomte)
Karte (oder Knopf), App setzt einen Node an dem Punkt nach GPS/Karte und
zeigt mir ein Tagset aus, idealerweise das vom Node vorher, in diesem
Falle trees=apple oder ähnliches.

Ich mag einfach ned aus mapillary alle Bäume manuell in die Karte
klicken und taggen.

Danke.

( z.B.:
https://www.mapillary.com/app/?lat=52.13998643270335=10.065918396861543=17=W4taLJSLgdk_-zbnLmYSCw=photo
oder
https://www.mapillary.com/app/?lat=52.14205438532002=10.058797920427423=17=Imrrhgn62962o0DaQKd8bQ=photo
)

MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723





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

[talk-cz] Openstreetmap.cz + Fody: koňské rozcestníky

[majkaz]

Nechybí nám ve Fody, resp. na openstreetmap.cz ikona koňského rozcestníku? 
Pokud je to jen koňský rozcestník, ukazuje se u vyfocených jako "unknown.png" - 
například https://osm.fit.vutbr.cz/fody/?id=22608

Nebo je tam ještě nějaká vada na kráse?

Majka

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

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Jérôme Seigneuret]

@Christian les académies sont des services déconcentrées mais sont quand
même découpées en fonction du territoire régional (ancien territoire avant
la fusion) par décomposition sur la base des départements au besoin pour
créer des académies
exemple PACA : Nice, Aix-Marseille
Les niveaux:
Région académique
Académie
DSDN - Directions des services départementaux de l'éducation nationale


Pour l'histoire les région académique sont arrivée suite à une loi de 2015

Une limite sur 3 niveaux. Des adresses comme direction
La zone scolaire est portée par l'académie. On a déjà vu des changements de
zones dans le temps

https://www.education.gouv.fr/cid3/les-regions-academiques-academies-et-services-departementaux-de-l-education-nationale.html


La partie SH se suffit à elle même c'est comme quand on parle des jours
férié.

France 2019 2020 2021
Jour de l'an mardi 1er janvier mercredi 1er janvier vendredi 1er janvier
Lundi de Pâques lundi 22 avril lundi 13 avril lundi 5 avril
Fête du Travail mercredi 1er mai vendredi 1er mai samedi 1er mai
Victoire des alliés mercredi 8 Mai vendredi 8 Mai samedi 8 Mai
Jeudi de l'Ascension jeudi 30 mai jeudi 21 mai jeudi 13 mai
Lundi de Pentecôte lundi 10 juin lundi 1er juin lundi 24 mai
Fête nationale dimanche 14 juillet mardi 14 juillet mercredi 14 juillet
Assomption jeudi 15 août samedi 15 août dimanche 15 août
La Toussaint vendredi 1er novembre dimanche 1er novembre lundi 1er novembre
Armistice lundi 11 novembre mercredi 11 novembre jeudi 11 novembre
Noël mercredi 25 décembre vendredi 25 décembre samedi 25 décembre
Le lundi de Pâques et le jeudi de L'ascension n'est jamais le même jours

Il est plus pertinent de définir une carte scolaire pour pouvoir matcher
avec la l'académie et donc la zone permettant de l'identifier.
Concernant les commerces je vais juste une question qui me trotte. As-t-on
des commerces/services qui seraient ouverts ou fermés mais sur la zone
d'une autre académie?



Le mar. 20 août 2019 à 12:45, Christian Quest  a
écrit :

> Le hic, c'est que les zones A/B/C sont liées aux académies et pas aux
> régions... et je ne sais pas si elles ne chevauchent pas des régions...
>
> Le mar. 20 août 2019 à 11:19, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> j'aurais tendance à commencer en testant l'ajout du SH sur
>> la relation Bourgogne-Franche-Comté, l'outil ayant l'air de
>> dire qu'il le prendrait en compte.
>> cela permettrait de vérifier qu'il n'y a pas d'autre problème
>> avant d'ouvrir un ticket sur l'outil et/ou d'en parler
>> sur tagging pour voir comment faire "harmonisé"
>>
>> Cordialement,
>> Marc
>>
>> Le 16.08.19 à 15:54, Yves P. a écrit :
>> > J'ai essayé la syntaxe suivante pour ce musée :
>> > Jul-Aug 10:30-18:30; May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa
>> > 13:30-18:00; SH Tu-Sa 13:30-18:00
>> >
>> > Le script renvoi l'erreur suivante :
>> > An error occurred during evaluation of the value "Jul-Aug 10:30-18:30;
>> > May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa 13:30-18:00; SH Tu-Sa
>> > 13:30-18:00". Please submit a pull request:
>> > https://github.com/opening-hours/opening_hours.js. There are no
>> holidays
>> > (SH) defined for country fr and state Bourgogne-Franche-Comté.
>> >
>> > __
>> > Yves
>> >
>> > https://openingh.openstreetmap.de/evaluation_tool/
>> >
>> >
>> >
>> >
>> > Le ven. 16 août 2019 à 15:50, Yves P. > > > a écrit :
>> >
>> > Bonjour,
>> >
>> > La syntaxe existe ("SH") mais il n' y a pas de définition pour les
>> > vacances solaires en France :
>> >
>> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/fr.yaml
>> >
>> > Comment définir les zones ?
>> > opening-hours ne semble utiliser que les régions (cf. README.md
>> > <
>> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/README.md
>> >)
>> >
>> > Il existe dans OSM des relations pour les zones scolaires :
>> >
>> >   * France, vacances scolaires, zone A
>> > 
>> >   * France, vacances scolaires, zone B
>> > 
>> >   * France, vacances scolaires, zone C
>> > 
>> >
>> > Il faut probablement soumettre une /"issue"/ dans opening_hours pour
>> > que le script gère directement ces relations et/ou les tags
>> > *holiday_zone* des relations *boundary educational.*
>> > *
>> > *
>> > Et/ou aussi étendre la syntaxe *SH* en spécifiant une zone ?
>> > SH A,C // vacances scolaires zone A et C
>> >
>> > J'ai un musée qui à des horaires d'ouvertures spécifiques pour les
>> > vacances scolaires quelque soit la zone :
>> > https://www.atelierdessavoirfaire.fr/
>> >
>> > En attendant, peut-on définir des vacances comme "Vacances xxx zone
>> Y" ?
>> >
>> > Exemple : Vacances d'hiver zone A
>> > https://www.education.gouv.fr/pid25058/le-calendrier-scolaire.html
>> >
>> > Fin 

[Talk-at] Graz, Trattenweg, Driveways, Parkflächen

[Lars Schimmer]

Hallo!

Habe gerade die neuen Gebäude im Trattenweg Graz a bissle akkurater
gesetzt und die Driveways eingetragen.

Hoffe das it OK so.

Dazu die Frage:

Auf
https://www.mapillary.com/app/?lat=47.052832148205134=15.443655183589744=17=4UmQPcbQeD_4uLQ-ZLTPcg=photo
erkennt man noch grob die Fläche vorm/unterm Haus bis zur straße
"Kasernenstraße" - dort sind Parkplätze für die Gäste des Hauses.
Wie trägt man die am besten ein?
service=driveway ist da weniger akkurat.

Danke


MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723





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

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[Christian Quest]

Le hic, c'est que les zones A/B/C sont liées aux académies et pas aux
régions... et je ne sais pas si elles ne chevauchent pas des régions...

Le mar. 20 août 2019 à 11:19, marc marc  a
écrit :

> Bonjour,
>
> j'aurais tendance à commencer en testant l'ajout du SH sur
> la relation Bourgogne-Franche-Comté, l'outil ayant l'air de
> dire qu'il le prendrait en compte.
> cela permettrait de vérifier qu'il n'y a pas d'autre problème
> avant d'ouvrir un ticket sur l'outil et/ou d'en parler
> sur tagging pour voir comment faire "harmonisé"
>
> Cordialement,
> Marc
>
> Le 16.08.19 à 15:54, Yves P. a écrit :
> > J'ai essayé la syntaxe suivante pour ce musée :
> > Jul-Aug 10:30-18:30; May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa
> > 13:30-18:00; SH Tu-Sa 13:30-18:00
> >
> > Le script renvoi l'erreur suivante :
> > An error occurred during evaluation of the value "Jul-Aug 10:30-18:30;
> > May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa 13:30-18:00; SH Tu-Sa
> > 13:30-18:00". Please submit a pull request:
> > https://github.com/opening-hours/opening_hours.js. There are no
> holidays
> > (SH) defined for country fr and state Bourgogne-Franche-Comté.
> >
> > __
> > Yves
> >
> > https://openingh.openstreetmap.de/evaluation_tool/
> >
> >
> >
> >
> > Le ven. 16 août 2019 à 15:50, Yves P.  > > a écrit :
> >
> > Bonjour,
> >
> > La syntaxe existe ("SH") mais il n' y a pas de définition pour les
> > vacances solaires en France :
> >
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/fr.yaml
> >
> > Comment définir les zones ?
> > opening-hours ne semble utiliser que les régions (cf. README.md
> > <
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/README.md
> >)
> >
> > Il existe dans OSM des relations pour les zones scolaires :
> >
> >   * France, vacances scolaires, zone A
> > 
> >   * France, vacances scolaires, zone B
> > 
> >   * France, vacances scolaires, zone C
> > 
> >
> > Il faut probablement soumettre une /"issue"/ dans opening_hours pour
> > que le script gère directement ces relations et/ou les tags
> > *holiday_zone* des relations *boundary educational.*
> > *
> > *
> > Et/ou aussi étendre la syntaxe *SH* en spécifiant une zone ?
> > SH A,C // vacances scolaires zone A et C
> >
> > J'ai un musée qui à des horaires d'ouvertures spécifiques pour les
> > vacances scolaires quelque soit la zone :
> > https://www.atelierdessavoirfaire.fr/
> >
> > En attendant, peut-on définir des vacances comme "Vacances xxx zone
> Y" ?
> >
> > Exemple : Vacances d'hiver zone A
> > https://www.education.gouv.fr/pid25058/le-calendrier-scolaire.html
> >
> > Fin des cours :
> > samedi 22 février 2020
> > Reprise des cours :
> > lundi 9 mars 202
> >
> >SH:
> >  - name: Vacances d'hiver zone A
> >'2020': [2, 23, 3, 8]
> >
> > Fichier pour l'Allemagne (contient des définitions pour les vacances
> > scolaires)
> >
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/de.yaml
> >
> > __
> > Yves
> > **
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Sur rendez-vous

[Topographe Fou]

Bonjour,

Il vaut mieux à mon sens éviter d'utiliser le champ opening_hours pour cela, 
sinon on en arrive à mélanger la maintenance des horaires avec celle des 
multiples possibilités de réservation (téléphone mais aussi Internet, sur 
place...). En plus le standard n'a pas forcément les mêmes horaires que les 
consultations. Idem pour Internet (24/7). La proposition de Marc est préférable 
à mes yeux : mettre la réservation sur un tag dédié (voir aussi la direction 
qui avait eu lieu en juin je crois sur la réservation hôtelière avec le débat 
booking=*) et laisser les horaires d'ouverture pour les horaires d'ouverture.

C'est bien différent d'un magasin qui n'ouvrirait que sur rendez-vous (sens de 
l'usage dans opening_hours). 

Cordialement, 

LeTopographeFou


  Message original  



De: marc_marc_...@hotmail.com
Envoyé: 20 août 2019 9:41 AM
À: talk-fr@openstreetmap.org
Répondre à: talk-fr@openstreetmap.org
Objet: Re: [OSM-talk-fr] Sur rendez-vous


Bonjour

Le 19.08.19 à 18:52, David Crochet a écrit :
> Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
>> je ne sais pas indiquer que voir la dentiste est uniquement « sur
>> rendez-vous »
>
> *opening_hours=xx:xx* |"||reservation by phone"|
>
> en remplacant xx:xx par les jours/horaires d'ouverture

il y aussi reservation=required
https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation

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

[Talk-es] Corrección de números de teléfono en Euskadi

[Jorge Sanz Sanfructuoso]

Hola

Como comente en telegram quiero editar de manera semi automática algunos
números de teléfono que están añadidos incorrectamente en Euskadi.

Estado mirando un poco cómo van las ediciones automatizadas según la wiki
por lo que he creado una pagina en la wiki para esta y más ediciones que
pueda hacer posteriormente y pido consulta aquí por si hubiera algún error
antes de proceder a las modificaciones.

Para la que nos atañe. La tengo documentada en
https://wiki.openstreetmap.org/wiki/Automated_edits/sanchi_bot#Correcci%C3%B3n%20de%20n%C3%BAmeros%20de%20tel%C3%A9fono%20de%20Euskadi%20(Agosto%202019)

En Euskadi hay algo más de 300 teléfonos puestos como phone
=9.44800802E8
.
Parece que es de alguna importación errónea. En un proceso semi automático
voy a proceder a quitar "E8" del final y añadir "+34" al principio. El
ejemplo quedaría así phone =+34
944 800 802
.
Le he añadido también los espacios y eliminado el punto que sobra después
del 9. He detectado alguno que no tiene 9 cifras pero los descarto para una
comprobación manual ya que no corresponde con un número de teléfono
estándar y son pocos casos.

Saludos.

-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanzs.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Vacances scolaires dans opening_hours

[marc marc]

Bonjour,

j'aurais tendance à commencer en testant l'ajout du SH sur
la relation Bourgogne-Franche-Comté, l'outil ayant l'air de
dire qu'il le prendrait en compte.
cela permettrait de vérifier qu'il n'y a pas d'autre problème
avant d'ouvrir un ticket sur l'outil et/ou d'en parler
sur tagging pour voir comment faire "harmonisé"

Cordialement,
Marc

Le 16.08.19 à 15:54, Yves P. a écrit :
> J'ai essayé la syntaxe suivante pour ce musée :
> Jul-Aug 10:30-18:30; May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa 
> 13:30-18:00; SH Tu-Sa 13:30-18:00
> 
> Le script renvoi l'erreur suivante :
> An error occurred during evaluation of the value "Jul-Aug 10:30-18:30; 
> May-Jun,Sep Tu-Sa 13:30-18:00; Dec We-Sa 13:30-18:00; SH Tu-Sa 
> 13:30-18:00". Please submit a pull request: 
> https://github.com/opening-hours/opening_hours.js. There are no holidays 
> (SH) defined for country fr and state Bourgogne-Franche-Comté.
> 
> __
> Yves
> 
> https://openingh.openstreetmap.de/evaluation_tool/
> 
> 
> 
> 
> Le ven. 16 août 2019 à 15:50, Yves P.  > a écrit :
> 
> Bonjour,
> 
> La syntaxe existe ("SH") mais il n' y a pas de définition pour les
> vacances solaires en France :
> 
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/fr.yaml
> 
> Comment définir les zones ?
> opening-hours ne semble utiliser que les régions (cf. README.md
> 
> )
> 
> Il existe dans OSM des relations pour les zones scolaires :
> 
>   * France, vacances scolaires, zone A
> 
>   * France, vacances scolaires, zone B
> 
>   * France, vacances scolaires, zone C
> 
> 
> Il faut probablement soumettre une /"issue"/ dans opening_hours pour
> que le script gère directement ces relations et/ou les tags
> *holiday_zone* des relations *boundary educational.*
> *
> *
> Et/ou aussi étendre la syntaxe *SH* en spécifiant une zone ?
> SH A,C // vacances scolaires zone A et C
> 
> J'ai un musée qui à des horaires d'ouvertures spécifiques pour les
> vacances scolaires quelque soit la zone :
> https://www.atelierdessavoirfaire.fr/
> 
> En attendant, peut-on définir des vacances comme "Vacances xxx zone Y" ?
> 
> Exemple : Vacances d'hiver zone A
> https://www.education.gouv.fr/pid25058/le-calendrier-scolaire.html
> 
> Fin des cours :
> samedi 22 février 2020
> Reprise des cours :
> lundi 9 mars 202
> 
>    SH:
>      - name: Vacances d'hiver zone A
>        '2020': [2, 23, 3, 8]
> 
> Fichier pour l'Allemagne (contient des définitions pour les vacances
> scolaires)
> 
> https://github.com/opening-hours/opening_hours.js/blob/master/holidays/de.yaml
> 
> __
> Yves
> **
> 
> 
> ___
> 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-it] Quesito stabile nuovo da mappare

[Andrea Albani]

Il giorno mer 14 ago 2019 alle ore 14:59 matteo soave 
ha scritto:

> Ciao a tutti. I ragazzi... non saprei , ma io mi sono perso sicuramente.
> Trovereste mal posto se chiedessi un ... riassuntino (a prova di
> schiocchino come me) su:
> - la materia del contendere: vi siete confrontati su 
> - siete d'accordo che ...
> - non tutti sono d'accordo su 
> Grazie ciao.
> Matteo
>

Ciao,

OSM è un progetto collaborativo caratterizzato da "regole" che sono state
costruite nel tempo dagli utenti stessi in base alle esigenze e in una
continua revisione che cerca di conciliare in punti di vista sia personali
che specifici di ogni realtà nazionale.
Quello che hai visto nel thread è un esempio di quanto su certi aspetti di
mappatura non ci sia ancora piena convergenza.

Nello specifico si è parlato di come attribuire un indirizzo agli elementi
presenti sulla mappa (tags addr:*). Abbiamo due "visioni":
A) i tag addr:*, e in particolare addr:housenumber, vanno associati al solo
numero civico, ovvero ad un nodo posto in prossimità dell'ingresso
contraddistinto da quel civico (regola valida in Italia)
motivazioni: non duplico l'indirizzo completo; i POI si possono trovare
comunque perchè si trovano in prossimità di un certo civico
B) i tag addr:*, housenumber compreso, vanno aggiunti anche ai Point Of
Interest (POI) che vado a mettere sulla mappa (amenity=restaurant,
shop=shoes, ...)
motivazioni: i POI sono così autoconsistenti perchè hanno in sè tutte le
informazioni per raggiungerli e non devo desumerle da altri elementi in
prossimità

Come corollario di A) per alcuni è accettabile mettere gli elementi del POI
sul medesimo nodo del civico (in modo da condividere i tag addr:*) SOLO se
a quel civico trovo SOLO quel POI (es. quando quel civico corrisponde
all'ingresso del negozio).

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

Re: [talk-cz] import SHP

[Jan Macura]

On Tue, 20 Aug 2019 at 09:21, majkaz  wrote:

> __
> > Od: "Jan Macura" 
> >Btw, nikde jsem nenašel možnost, že by JOSM uměl načíst Shapefile..? Musel
> >jsem si doinstalovat plugin i na ten GeoJSON.
> >[image: jeskyne_na_pomezi_qgis.PNG][image: jeskyne_na_pomezi_josm.PNG]
> >
>
> Měl by umět plugin OpenData, ale používám to k jiným účelům, takže je
> třeba prověřit.
>
>
Dík za tip. Potvrzuji, že OpenData plugin načíst Shape umí. Jen JOSM tu
transformaci S-JTKS->WGS84 sám nedává, takže stejně je potřeba v GISu
minimálně transformovat (a s GeoJSONem se pracuje mnohem líp, než s
Shapefilem, takže asi tak.. :-) ).

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

Re: [OSM-talk-fr] Sur rendez-vous

[pepilepi...@ovh.fr]

Le 20/08/2019 à 09:39, marc marc a écrit :
> Bonjour
>
> Le 19.08.19 à 18:52, David Crochet a écrit :
>> Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
>>> je ne sais pas indiquer que voir la dentiste est uniquement « sur 
>>> rendez-vous » 
>> *opening_hours=xx:xx* |"||reservation by phone"|
>>
>> en remplacant xx:xx par les jours/horaires d'ouverture
> il y aussi reservation=required

C'est exactement ça ! (je connaissais pas, merci)

Bonne journée,

JP

> https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question


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

Re: [Talk-at] Import von BEV Adress- Stichtagsdaten Österreich

[Frederik Ramm]

Hi,

Bestandteile eines ordentlichen Imports sind unter anderem:

* Prüfung, ob die Lizenz der Quelldaten geeignet ist.

* Dokumentation, wie der Import handwerklich erfolgen soll - mit welchen
Programmen werden die Daten konvertiert, welche Tags dabei verwendet,
mit welchem Tool wird hochgeladen, wie wird dabei sichergestellt, dass
bestehende Daten nicht kaputt gehen, und so weiter.

* Wie wird die Community einbezogen. Sitzt irgendwo einer an seinem
Rechner und überzieht das ganze Land, inklusive Gegenden, die er noch
nie gesehen hat, mit Importen (eher schlecht) oder bereitet einer Daten
vor, die dann von Ortskundigen sorgfältig eingepflegt wrden können (eher
gut)?

* Dokumentation auf einer Wikiseite

(Das ist alles in den schon mehrfach zitierten Guidelines festgelegt.)

Wenn alle diese Aspekte fest stehen und auf dem Tisch liegen, dann kann
die Community entscheiden, ob sie den Import gutheisst oder nicht.

Bye
Frederik

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

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

Re: [OSM-talk-be] Neighbourhoods in Ghent mapped as a point

[Lionel Giard]

Yes the node approach is only done when the boundaries are unknown (and so
this is an approximation) but in this case, as we have the boundaries as
open data, we could add them indeed. You can see it in the wiki page too
. Thus, creating a polygon
using the exact boundaries of the open data with the tag
"place=neighbourhood" + "name=*" should be fine. You can just import a
shapefile or similar format in JOSM for example, and tag it correctly.

Le lun. 19 août 2019 à 10:35, Pieter Colpaert  a
écrit :

> Hi all,
>
> Neighbourhoods in Ghent are mapped as a point. See for example
> https://www.openstreetmap.org/node/2274965455
>
> The problem with this is that nominatim will add the neighbourhood to an
> address string, based on the nearest point. An address still in the
> Brugse Poort therefore will get an obvious wrong neighbourhood attached
> to it. See for example
>
> https://nominatim.openstreetmap.org/search.php?q=appelstraat+27%2C+9000+Gent_geojson=1=.
>
> This point is in the Brugse Poort, but it is closest to the point of the
> neighbourhood Malem.
>
> Should we change these point to be polygons instead?
>
> There is also an official Open Data list of “wijken” (which is not
> entirely the same though) on the open data portal of the city of Ghent:
> https://datatank.stad.gent/4/grondgebied/wijken → Should we map these
> bounds in OSM as well? And how?
>
> Kind regards,
>
> Pieter
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Sur rendez-vous

[marc marc]

Bonjour

Le 19.08.19 à 18:52, David Crochet a écrit :
> Le 19/08/2019 à 18:39, Jacques Lavignotte a écrit :
>> je ne sais pas indiquer que voir la dentiste est uniquement « sur 
>> rendez-vous » 
> 
> *opening_hours=xx:xx* |"||reservation by phone"|
> 
> en remplacant xx:xx par les jours/horaires d'ouverture

il y aussi reservation=required
https://wiki.openstreetmap.org/wiki/FR%3AKey%3Areservation

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

[OSM-Talk-ZA] Improving OpenStreetMap

[Sindile Bidla]

Hello Community,

I was contacted by Aaron Young (copied) of kaartgroup.com a while back here
is an extract from his email:

My organization, Kaart.com  is currently in the process
of updating road names for South Africa in OpenStreetMap.org
.  You can see our most recent work in Cape Town
and Durban.  Would you be able to provide street names to fill in missing
names for users of OpenStreetMap?  We are more than happy  to do the import
ourselves if you are able to provide the data to us.  We are most
insterested in East London, Grahamstown, and other rural towns in the
Eastern Cape.  
http://qa.poole.ch/?zoom=8=-32.51065=27.48572=TFFFB0


In response I provided him with the following information:

The Provincial Department of Transport embarked on a project sometime in
2010 to 2014 - here is the project website - http://www.roadclass.co.za/

The individual files per municipality are found in this link -
http://www.roadclass.co.za/index.php/kmz-downloads/

I have though created a geopackage available here -
https://drive.google.com/open?id=1S2IzsppDZlXXLCRp5q6Q2pC5ZF83dGv1

This data excludes the datasets for Nelson Mandela Metro and Buffalo City
Metro.

I generally use this data with OSM - please review it. In South Africa data
generated by government is Public Data, but if you have licensing
considerations I can try and clear them with the Provincial Department of
Transport.

Please also not a while back I facilitated the provision of address data to
the openaddress project for the entire country based on data from
Statistics South Africa.

What if we leveraged this data to get road names?

I am also available to work with your team to address any other issue you
might have in improving the data on OSM.

We then subsequently agreed to move this discussion to solicit ideas and
involvement by the community.

Regards,

Sindile Bidla
___
Talk-ZA mailing list
Talk-ZA@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-za

Re: [talk-cz] import SHP

[majkaz]

__
> Od: "Jan Macura" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 20.08.2019 00:25
> Předmět: Re: [talk-cz] import SHP
>

>Btw, nikde jsem nenašel možnost, že by JOSM uměl načíst Shapefile..? Musel
>jsem si doinstalovat plugin i na ten GeoJSON.
>[image: jeskyne_na_pomezi_qgis.PNG][image: jeskyne_na_pomezi_josm.PNG]
>

Měl by umět plugin OpenData, ale používám to k jiným účelům, takže je třeba 
prověřit.

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

Re: [Talk-it] allevamenti di polli

[Lorenzo Beltrami]

Ciao Paola,

Il giorno lun 19 ago 2019 alle ore 21:13 Paola via Talk-it <
talk-it@openstreetmap.org> ha scritto:

> Viste le varie combinazioni però mi sorge una domanda... ci sono
> differenze tra usare ad esempio:
> a) building=cowshed
> b) building=yes amenity=animal_breeding animal_breeding=cow;
> c) landuse=farmyard animal_breeding=cow;
> d) landuse=farmyard livestock=poultry poultry=chicken
>
> o dipende solo dal numero di utenti che hanno utilizzato i vari tag?
>

sì, ci sono alcune differenze che provo ad elencarti di seguito:
building=cowshed[0] indica un edificio costruito come stalla per mucche (è
un'etichetta che indica una cosa ben precisa)
building=yes[1] indica un edificio di cui non si conosce la tipologia
(potrebbe essere una casa, una baracca, un silo...), ma si sa solo che è un
edificio. Spesso è un passaggio preliminare che viene poi "convertito" in
un'etichetta più precisa, come ad esempio quella di prima, building=cowshed
amenity=animal_breeding[2] indica un'attività dove si allevano animali
(potrebbe essere messo sull'area dell'intera azienda oppure su punto che ne
indica approssimativamente la posizione)
animal_breeding=cow[2] indica che in quell'allevamento si allevano mucche
landuse=farmyard[3] indica che un dato terreno viene utilizzato come
fattoria (la zona di un'azienda agricola in cui ci sono gli edifici e le
aree di lavoro)
livestock=* è una chiave che non ho trovata documentata sulla wiki, quindi
non saprei dirti di preciso per cosa viene usata... Così su due piedi direi
che indica il tipo di bestiame presente in un dato elemento, nel nostro
caso specifico mi sembrerebbe un doppione di animal_breeding=*...

Quindo tornando ai tuoi esempi:
a) indica una stalla per mucche
b) indica un edificio generico in cui c'è un allevamento di mucche
c) indica una fattoria in cui si allevano mucche, ma senza specificare che
è un allevamento (siccome manca amenity=animal_breeding)
d) indica una fattoria in cui è presente del pollame e quel pollame sono
galline (non viene indicato a cosa serve quel pollame)

Nel caso di un allevamento si pollame io farei così:
landuse=farmyard su ogni area che include gli edifici e gli spazi di lavoro
(la fattoria)
se quest'area coincide con l'azienda di allevamento allora si aggiunge
sempre sullo stesso elemento amenity=animal_breeding +
animal_breeding=poultry (si può anche aggiungere produce=meat se è pollame
da carne o produce=eggs se è pollame da uova)
Se l'azienda non è chiaramente sovrapponibile con l'area della fattoria
allora amenity=ecc. ecc. si può mettere su un nodo all'interno della
fattoria stessa o comunque dove si vuole indicare l'allevamento.
Sui singoli edifici che ospitano il pollame si potrebbe mettere
building=poultry_house (su Taginfo, uno strumento che raccoglie statistiche
sui tag presenti in OSM, è indicato come utilizzato già 1389 volte).

Scusate faccio un'altra domanda, ho preso (a caso) questa way
>
> https://www.openstreetmap.org/way/249300679
>
> mettiamo sia un allevamento di pollame, per aggiungere informazioni
> (utilizzando una delle combinazioni sopra) è necessario contattare chi ha
> creato la way o si possono modificare/aggiungere direttamente?
>

Puoi assolutamente modificarlo tu direttamente! ;-)
Vai sul sito (se non l'hai ancora fatto ti registri) e poi con il tasto
"Modifica" puoi modificare la mappa aggiungendo/modificando ciò che conosci.
È buona norma prestare attenzione quando si modifica il lavoro fatto da
altri, ma se si aggiungono o si completano informazioni mancanti
solitamente non ci sono grossi pericoli. :-)

Ciao!
Lorenzo

[0] https://wiki.openstreetmap.org/wiki/Tag:building%3Dcowshed
[1] https://wiki.openstreetmap.org/wiki/Key:building
[2] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Danimal_breeding
[3] https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmyard
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-at] Relationschaos nach Landesstraßenanpassung (Kreisverkehr Erstellung)

[Andreas via Talk-at]

Am 17.08.19 um 23:09 schrieb Robert Grübler:
> 
> Andreas wrote:
>> Gibt es dazu einen leichteren Weg, oder ist es einfach mit den Relationen so 
>> kompliziert?
> 
> Freut mich, dass du so aufmerksam auf die Relationen geachtet hast.
> Ja, man kann sich die Sache leichter machen, indem man keine neuen Wege 
> anlegt, sondern vorhandene umformt. Damit vermeidet man eine individuelle 
> Nacharbeit der einzelnen Relationen. Einfach ist es aber nur bedingt.

Die Workflows fürs Umformen waren mir nicht bekannt. Habe eh vorher
etwas gesucht, aber dann habe ich einfach die Sache mit dem Teilen
gemacht. Werde deine Vorschläge aber in meine JOSM Tipps Sammlung aufnehmen.

Danke

Geologist
> 
> 
> 1.) Neuer Kreisverkehr in vorhandener Straße
> ===
>* vorhandene Straße dort teilen, wo später die Anschlussstellen an den 
> Kreisverkehr sein werden
>* das mittlere Segment wählen
>* shift-O drücken
>* fertig
> Ref.: https://forum.openstreetmap.org/viewtopic.php?id=57819 
> 
> 
> 2.) Neuer Kreisverkehr in vorhandener Kreuzung
> =
>* vorhandene Straßen einige Meter vor der späteren Anschlussstelle teilen 
>* im Kreuzungspunkt alle Linie trennen (G)
>* alle Linien vom Kreuzungspunkt zurückziehen bis zur späteren 
> Anschlussstelle an den Kreisverkehr
>* alle Linien erweitern und mit einem Zwischenpunkt in der Nähe des  
> jeweiligen Endknoten des rechten Nachbarn platzieren (Endknoten wählen, A)
>* nun alle Erweiterungen mit den ursprünglichen Endknoten der rechten 
> Nachbarn verbinden (M). Damit ist der Kreis geschlossen
>* Kreis durch Teilen von Ausläufern befreien, Richtungen der Kreissegmente 
> anpassen (CCW), exakt zum Kreis formen (O)
>* alle Kreissegmente wählen und Tag "junction=roundabout" hinzufügen
>* alle Kreissegmente wählen und vereinen (C). Bei Konfliktbereinigung auf 
> doppelte Wege achten.
>* fertig
> Ref. (Teilschritte):  
> https://docs.google.com/document/d/1McI0qbciWiy9A3jC0ZEkKiu5AzLRFqqb-jBoVGjnB0Y/edit
>  
> 
> 
> 3) Damit die Pflege der Relationen, insbesondere die des ÖPNV, einfacher wird
> =
>* Kreisverkehr NICHT segmentieren, außer die Segmente benötigen 
> unterschiedliche Tags
>* ankommende Straßen möglichst NICHT splitten. 
> Eine kleine Verkehrsinsel, die Zu- uns Abfahrt trennt, soll mit einem 
> Extra-Knoten vor dem Kreisverkehr mit "traffic_calming=island" gekennzeichnet 
> werden.
> 
> 
> 4) Ankommende Straße splitten
> =
> Nur bei ausgeprägt baulich getrennte, richtungsabhängige Fahrspuren mit Fuß- 
> und/oder Rad-Übergängen!
>* Knoten bei Beginn der Fahrspurtrennung setzen
>* Segment Knoten-Kreisverkehr in der Mitte auftrennen
>* aus den zwei Teilen Zu- und Abfahrt formen
>* Kreisverkehr segmentieren
>* Rollen verteilen, Segmente sortieren
> Der letzte Schritt ist sehr arbeitsintensiv, da er für alle Relationen 
> manuell durchzuführen ist.
> 
> Wenn  durch ein neuen Kreisverkehrs viele Relationen zerstört wurden, mache 
> ich aus dem Kreisverkehr wieder eine Kreuzung mit intakten Relation und 
> erstelle den Kreisverkehr neu nach dem o.a. Verfahren.
> 
> LG Robert
> 
> 
> 
> 
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




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