Re: [OSM-talk] Help me build an OSM Community Index

[Johannes Singler]

Hi,

I think this is a great idea for community building.

BTW what about having similar functionality *during* editing?  For 
example showing a link to the OSM wiki page of the currently edited area?
Such pages often tell what to pay special attention to in a certain 
area, but IMHO they would deserve more visits (which could be improved 
by showing such links).


Johannes

Am 31.03.2018 um 14:25 schrieb Bryan Housel:

I’ve started building an index of OSM community resources here:
https://github.com/osmlab/osm-community-index

"Resources" can be links to forums, meetups, Slack groups, Facebook 
groups, mailing lists, and so on. Anything that mappers, especially 
beginners, might find interesting or helpful.


*Why?*

Currently when you save an edit in iD, you will see a screen prompting 
you to share your edit on Facebook, Twitter, Google+.  But we’d prefer 
instead to use this screen to let the user know more about the community 
around where they are editing.


See https://github.com/openstreetmap/iD/issues/4815  for discussion and 
some mockups.


While the initial use of this index will be primarily to support this iD 
feature that will be released soon, I’d love to see other applications 
that have a community focus use the index as well.  For example, if you 
are reviewing an edit in OSMCha, and you see something that looks like 
vandalism or an undiscussed import and you want to ask someone in the 
local community to take a look, this index could tell you how to reach 
out to somebody local.



*What about { existing lists / the OSM wiki }?*

I did look at existing community lists, and there are several, but most 
of those lists do not support adding a bounding polygon around a 
community.  Several of them do let you place a single pin where the 
community is, but I was looking for something that would let me draw 
complex bounding areas, and filter to only show communities active 
around in the area where a user is editing.


We already have a successful project for sharing imagery sources that 
editors can use (see https://github.com/osmlab/editor-layer-index ) so I 
decided to create something very similar.



*How can I help?*

Glad you asked!
1.  Go to https://github.com/osmlab/osm-community-index/  and watch or 
star the project. ⭐️


2.  Read the README and CONTRIBUTING documents.  These contain info 
about which files need to be added:


  * Each resource needs a `.json` file to describe it, and
  * a `.geojson` file to describe where the region where it is active.
  (multiple resources can share a .geojson file)


3.  Either add the files with a Pull Request, or open an issue for 
somebody else to add the files.



Thanks!
Bryan






___
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] Sidewalk symmetry

[Andrew Harvey]

On 18 April 2018 at 06:30, Jmapb  wrote:

> (My personal feeling is that that it's better to avoid mapping sidewalks
> as separate ways unless there's a compelling reason that would outweigh the
> additional data clutter and routing complications. In some circumstances --
> those where walking on the sidewalk, or on a particular side of a road with
> two sidewalks, has noticeably different routing implications -- it seems
> like a good idea.)
>

It means less tags on the road which makes it easier to edit manually. A
road already has:

highway, surface, maxspeed, maxweight, maxheight, width, oneway, access,
lanes, turn:lanes, lit, parking:lane:left, parking:lane:right,
parking:condition:left, parking:condition:right,parking:lane:left:type,
parking:lane:right:type, etc.

A sidewalk also has it's own:

maxspeed (some places where bicycles can use the sidewalk and sections have
signposted speed), maxweight, width, access, surface

On top of that the highway needs to be split every time just one of those
tags changes meaning you end up with many short segment ways.

I realise editors can and do abstract some of this, but if we can put all
those sidewalk attributes on their own ways it makes it much easier to map
by reducing the complexity of the highway centerline.

It means we can use say the exact same tags on the separate sidewalk rather
than prefixing them with sidewalk:left:width, sidewalk:left:bicycle, etc.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Martin Koppenhoefer]

sent from a phone

> On 18. Apr 2018, at 00:00, Francesco Frassinelli  wrote:
> 
> - OSM segna come benzinaio l'edificio e non la tettoia con le pompe (come 
> pare fare il dataset MISE) -> giusto o fixme (e se sì, cosa scriverci?)


non vedo un grosso problema, si può anche disegnare tutta l’area del benzinaio 
(compreso edifici)


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

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Francesco Frassinelli]

Il giorno 17 aprile 2018 14:31, Cascafico Giovanni  ha
scritto:

> La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
> (includendo anche i waterway=fuel).
> Nella procedura di import è successivamente previsto un "audit"
> (revisione) dei risultati, come illustrato in questo [1] schema.
>

Ottimo, grazie!


> - fixme (opzionale)
> una breve nota dei problemi (per esempio il distributore in OSM è spostato
> rispetto immagine aerea)
>

Ho qualche dubbio su quando e come usare il tag fixme in questi casi:
- OSM segna come benzinaio l'edificio e non la tettoia con le pompe (come
pare fare il dataset MISE) -> giusto o fixme (e se sì, cosa scriverci?)
- Posizione semplicemente sbagliata -> fixme con quale commmento?

Avete altri consigli a riguardo? Grazie! :-)


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

Re: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Paul Norman]

On 3/26/2018 1:24 PM, Rory McCann wrote:

Any ideas for topics?


Some ideas

- Regional languages. Is there a regional language you speak? Make sure 
that you're adding it to the map when objects have a name in that 
language. Unfortunately, this isn't great for a global project because 
not everyone can do it.


- Traditionally "blue-collar" areas. It's fairly well known that these 
are underrepresented in OSM, and there's a lot of mapping that can be 
done remotely. Something I've worked on has been mapping industrial 
parks. For these, a basic mapping would be buildings, industrial area 
names, building numbers, landuse, and service roads on them. Many 
industrial parks have places to eat to serve the workers around them and 
these are important to map too. There's lots more that could be mapped, 
but this would be a good start.


- Wheelchair access has lots of resources, but isn't underrepresented in 
OSM mapping.


___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[liste DOT girarsi AT posteo DOT eu]

Il 17/04/2018 14:31, Cascafico Giovanni ha scritto:

La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
(includendo anche i waterway=fuel).
Nella procedura di import è successivamente previsto un "audit" (revisione)
dei risultati, come illustrato in questo [1] schema.

A mio parere non è necesario validare tutti i 20709 nodi per proseguire
nell'import, ma la revisione della comunità è comunque un passo importante.

Effettuare una revisione collaborativa è abbastamza semplice: si va alla
pagina del progetto di audit [2].


Questo:

Transparent marker is the external dataset point location.


Sarebbe da considerare duplicate?

La posizione di un POI è giusta con informazioni valide, poi a fianco 
c'è uno trasparente.

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

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

[OSM-talk-fr] Wiki des cours d'eau

[François Lacombe]

Bonsoir à tous,

Pour info, s'achève ce soir une vague de mise à jour du wiki pour la
cartographie des cours d'eau, en anglais pour commencer et intégralement
traduite en français ensuite.
https://wiki.openstreetmap.org/wiki/FR:Waterways

Les tags utilisés se veulent équilibrés entre le cours d'eau lui-même, son
contenant éventuel lorsque des structures artificielles sont construites,
et enfin son usage.
waterway=* (le cours d'eau)
tunnel=* / bridge=* (contenant artificiel éventuel)
usage=* (utilisation)

Cela suite à l'adoption de la proposition de cartographie des ouvrages
d'amenée d'eau
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Hydropower_water_supplies

Parmi les nouveaux tags, on a :
https://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dpressurised
https://wiki.openstreetmap.org/wiki/FR:Tag:usage%3Dheadrace
https://wiki.openstreetmap.org/wiki/FR:Tag:usage%3Dtailrace
https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded

Le nécessaire a été fait auprès des rendus et éditeurs notables, néanmoins
rien ne sera mis en place tant que ces tags ne sont pas plus utilisés.
Bref, si vous connaissez des ouvrages dignes d’intérêt dans votre zone,
servez-vous en

Bonne soirée

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

Re: [Talk-it] Mappe mute

[Martin Koppenhoefer]

sent from a phone

> On 17. Apr 2018, at 10:25, Cascafico Giovanni  wrote:
> 
> Grazie, sto provando mapz adesso. Maperitive mi pare sia solo disponibile per 
> windows.


si, ma credo ci siano possibilità di utilizzarlo su altri sistemi, per esempio 
con mono. 

Ciao,
Martin 




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

[OSM-talk] Sidewalk symmetry

[Jmapb]

The wiki contains some suggestions/guidelines about when to map 
sidewalks as separate footways versus when to encode them as tags on the 
main road. The basic recommendation seems to be that if there's a 
barrier or even a strip of grass between the two, a separate way is fine 
and even sometimes preferred (and the road should be tagged 
sidewalk=separate to indicate that it's been mapped as a separate way), 
but if the sidewalk is directly adjacent to the road, better to just 
imply it with a sidewalk=left/right/both tag.


My gut tells me that a corollary should be: If the sidewalk on one side 
of the road is mapped as a separate way, then the sidewalk on the other 
side (if there is one) should also be a separate way, even if it's 
directly adjacent to the road due to asymmetry of sidewalk design. Does 
this sound right? I certainly don't see any clean way to tag a road to 
indicate that one of its sidewalks has been mapped as its own way and 
the other hasn't.


(My personal feeling is that that it's better to avoid mapping sidewalks 
as separate ways unless there's a compelling reason that would outweigh 
the additional data clutter and routing complications. In some 
circumstances -- those where walking on the sidewalk, or on a particular 
side of a road with two sidewalks, has noticeably different routing 
implications -- it seems like a good idea.)


Thanks for you thoughts, jmb


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

[Talk-GB] Addressing of flats: review best practice

[Andrew Hain]

I have been mapping a complex of flats that consists of a series of blocks each 
with its own entrance, tagging each section with addr:housename and addr:flats 
[https://www.openstreetmap.org/way/580234651]. The standard layer repeats the 
name of the whole block for each section, which I find a bit clunky 
(Humanitarian doesn’t label anything at all). Before I discuss this with the 
map renderers, am I doing the best thing for tagging?


--

Andrew

[https://www.openstreetmap.org/assets/osm_logo_256-cde84d7490f0863c7a0b0d0a420834ebd467c1214318167d0f9a39f25a44d6bd.png]

Way: 580234651 | OpenStreetMap
www.openstreetmap.org
OpenStreetMap is a map of the world, created by people like you and free to use 
under an open license.

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

[Talk-GB] Leicester pub meeting & mapathon Thursday 19th April

[SK53]

Just another reminder that we have an extra couple of events this week in
Leicester.

The Mapathon is in the Bennett Building, University of Leicester from
16:30. I'd welcome anyone who is willing to lend a hand to help any
newcomers get off the ground. I'm detailing stuff on this wiki page:
https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup/Leicester_Mapathon

We'll meet in The Parcel Yard right next to Leicester Station from 19:00
which gives a reasonable length of time for those who need to catch trains
early, and hopefully will avoid people having to rush for trains. This pub
will give everyone the chance to decide if its a pub or a bar as currently
mapped. It's large & airy and has reasonable options for food until 21:00.
Leicester City are at home on Thursday so there is an outside chance the
pub will be a little busy at the start of the evening.

I've contacted a few active mappers in the Leicester area.

Best wishes,

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

Re: [Talk-it] building:levels

[scratera]

...anche perchè se io scrivessi building:levels=0 in questo rendering
sparirebbero parecchi building

http://demo.f4map.com/#lat=45.8906495=11.0485324=16=76.849=-84.225



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

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

Re: [OSM-talk] GDPR introduction

[Simon Poole]

Am 17.04.2018 um 19:37 schrieb Michael Reichert:
> 
> *Controller vs. processor*
>
> Chapter "Recommendations", section 3 (page 10) writes:
>> Using the data for user and contribution profiling will either require a data
>> processing agreement (and a similar agreement for research) or the the OSM
>> data consumer needs to operate as an independent data controller (see
>> below)..
> Does this mean that someone who runs a service to fight vandalism and
> other bad edits has the choice to either sign a data processing
> agreement with the OSMF or to work as independent data controller? I am
> not sure because section 5 on the same page writes:
There are essentially 3 routes that we could take:
 
- not distribute meta-data to third parties at all (sure to be very
popular :-))
- a controller - data processor type arrangement. Besides the construct
being a bit contrived in our case, the typical data-processing
agreements I've seen are rather large legal monsters that are not going
to be easy on anybody, but we are not going to rule this completely out,
at this point in time-
- the entities processing the data are doing so on their own behalf and
are acting as independent controllers (which is more what is really
going on in any case)

>> Entities receiving full data (that is including metadata) are expected to 
>> operate as
>> independent controllers.
> Working as data processor has the disadvantage that the service provider
> has to sign some piece of paper. 
A DPA is definitely not some piece of paper :-) (make that 10+)
> On the other hand it provides safety
> for them. If a service provider acts as data controller any OSM user can
> ask him to delete his user data?

Well that depends on the reasoning the controller uses to document that
the processing of personal data is "lawful", as the data hasn't directly
been obtained from the data subject you will not be able to rely on
consent as a basis, but likely similar legitimate interests arguments
could be made as the OSMF will likely do (vandalism protection, QA, and
so on).

> Users asking the service providers instead of the OSMF to delete their
> data add addition hassle to the service provider and harm the
> development of OSM:
>
> - The service provider has to "filter" incoming data from OSM (diffs,
> planet dump, …) to remove data they are not permitted to use.
>
> - The community is unable to review edits of that user using the
> third-party service because the user is not visible there. Users with
> bad faith (they exist and I know a few examples) can use that to do
> edits below the radar and make validation and reverts of their edits
> difficult.

We intend to provide a list of "deleted users" or rather user ids so
this shouldn't be all to difficult, but the entities processing the data
will need to make their own determination on how to handle the deletions.

>
> That's why I would like to ask the OSMF to let service providers choose
> their favourite legal model. If the service provider chooses to be a
> data processor, he can redirect incoming request of deletion to the OSMF
> and the OSMF has to delete the user and block his account. The latter
> makes further validation of his edits mostly unnecessary.
>
>
> *Timestamps*
>
> Appendix B writes:
>> It can be argued that completely removing timestamps causes a significant 
>> loss of
>> functionality and information, for example when an object was last updated. 
>> This
>> could be partially rectified by simply reducing the granularity of the 
>> timestamps in
>> publicly available data, for example by only displaying dates.
> Removing user names, user IDs and changesets from data dumps and general
> API access does not really harm most usage of OSM. However, one change
> might cause more trouble if it were seriously followed through – the
> timestamps.
>
> If you reduce their granularity to one day, it is still possible to
> group edits in areas with a low density of mappers. I am not talking
> about central Sahara, the poles or the Middle West of the U.S. I am
> talking about almost all areas of Central and Western Europe except the
> metropolitan areas.
>
> See the following picture of my master thesis
> https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png
>
> It shows the frequency of map edits in the north-east of Germany between
> 2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
> imported the hourly diffs from OSM into my database. Dark blue means
> that within more than one month, less than four diffs contained updates
> for that area. You would have to reduce the granularity to a month to
> make the recreation of changesets impossible!
>
> Slide 15 of
> http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf
> shows the same for California. It is possible to group edits in the Bay
> Area if the granularity is 

Re: [OSM-talk] GDPR introduction

[Michael Reichert]

Hi Simon,

Am 2018-04-17 um 12:48 schrieb Simon Poole:
> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> * will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
> 
> The LWG has prepared a position paper on the matter that has been
> reviewed by data protection experts and in general the approach to not
> rely on explicit consent has been validated. It should be noted that
> while the paper outlines our approach, some of the details still need to
> be determined. In particular the future relationship with community and
> third party data consumers that utilize OSM meta-data and what will
> actually be dropped/made less accessible of the data listed in Appendix B.
> 
> LWG GDPR Position Paper
> 
> 
> Please feel free to discuss on the talk page
>  or on this list.

I would like to thank you for your work and agree that the OSMF should
not ignore GDPR. I think that it is a huge step forwards in terms of
data protection in general.

*Controller vs. processor*

Chapter "Recommendations", section 3 (page 10) writes:
> Using the data for user and contribution profiling will either require a data
> processing agreement (and a similar agreement for research) or the the OSM
> data consumer needs to operate as an independent data controller (see
> below)..

Does this mean that someone who runs a service to fight vandalism and
other bad edits has the choice to either sign a data processing
agreement with the OSMF or to work as independent data controller? I am
not sure because section 5 on the same page writes:
> Entities receiving full data (that is including metadata) are expected to 
> operate as
> independent controllers.

Working as data processor has the disadvantage that the service provider
has to sign some piece of paper. On the other hand it provides safety
for them. If a service provider acts as data controller any OSM user can
ask him to delete his user data?

Users asking the service providers instead of the OSMF to delete their
data add addition hassle to the service provider and harm the
development of OSM:

- The service provider has to "filter" incoming data from OSM (diffs,
planet dump, …) to remove data they are not permitted to use.

- The community is unable to review edits of that user using the
third-party service because the user is not visible there. Users with
bad faith (they exist and I know a few examples) can use that to do
edits below the radar and make validation and reverts of their edits
difficult.

That's why I would like to ask the OSMF to let service providers choose
their favourite legal model. If the service provider chooses to be a
data processor, he can redirect incoming request of deletion to the OSMF
and the OSMF has to delete the user and block his account. The latter
makes further validation of his edits mostly unnecessary.


*Timestamps*

Appendix B writes:
> It can be argued that completely removing timestamps causes a significant 
> loss of
> functionality and information, for example when an object was last updated. 
> This
> could be partially rectified by simply reducing the granularity of the 
> timestamps in
> publicly available data, for example by only displaying dates.

Removing user names, user IDs and changesets from data dumps and general
API access does not really harm most usage of OSM. However, one change
might cause more trouble if it were seriously followed through – the
timestamps.

If you reduce their granularity to one day, it is still possible to
group edits in areas with a low density of mappers. I am not talking
about central Sahara, the poles or the Middle West of the U.S. I am
talking about almost all areas of Central and Western Europe except the
metropolitan areas.

See the following picture of my master thesis
https://user-images.githubusercontent.com/3611273/36112876-50bbe552-102b-11e8-9857-23b868017013.png

It shows the frequency of map edits in the north-east of Germany between
2016-08-29 and 2016-10-05. Edits on relations have been ignored. I
imported the hourly diffs from OSM into my database. Dark blue means
that within more than one month, less than four diffs contained updates
for that area. You would have to reduce the granularity to a month to
make the recreation of changesets impossible!

Slide 15 of
http://tib.flowcenter.de/mfc/medialink/3/de416ce499d2c0ef194390304b67c5a08d22fbd5cff5af05bd6931d24f4016b2b9/FOSSGIS2017-5147-qualitatssicherung_mit_vektortiles.pdf
shows the same for California. It is possible to group edits in the Bay
Area if the granularity is reduced to one day.

I agree that timestamps can be used to group edits but it is not
possible to group them properly and you still don't know who uploaded
the changeset. That's where personal information 

Re: [Talk-it] building:levels

[Martin Koppenhoefer]

sent from a phone

> On 17. Apr 2018, at 18:32, scratera  wrote:
> 
> https://wiki.openstreetmap.org/wiki/Key:building:levels
> ...personalmente per mè il livello 0 è il livello del suolo...casa con
> appartamento solo al piano terra  building:levels=1



ci sono 2 tag, uno per indicare il piano su cui si trova qualcosa
level=0 è piano terra 
building:levels invece il numero di piani (sopra terra e senza il tetto)


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

Re: [Talk-it] building:levels

[Jeawrong]

Perfetto, ora mi è chiaro ;)



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

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

Re: [Talk-it] building:levels

[Alessandro]

Il 17/04/2018 18:15, Jeawrong ha scritto:

Salve, mi è sorto un dubbio riguardo al tag in questione: nelle pagine del
wiki (sia italiana che inglese) si legge che "Il tag building:levels è usato
per indicare i piani sopraelevati di un edificio", ("The building:levels tag
is used for marking the number of above-ground levels" nella pagina inglese)
quindi il piano terra è 0, il primo piano è 1, insomma la classica
definizione che si trova anche sulle pulsantiere degli ascensori. Il disegno
esemplificativo però indica tutt'altro, come se il piano terra sia da
considerare piano 1. Forse si tratta solo di un malinteso tra il disegno e
quanto scritto, ma se io entro in un pian terreno non entro in alcunchè di
sopraelevato rispetto al piano stradale. Qual'è il modo corretto dunque?




Come scrive Scratera significa il numero di piani sopra il suolo: casa 
ad un piano -> building:level=1
Mi sono tolto il dubbio prima che iniziassi a mappare anche con 
StreetComplete.


Alessandro Ale_Zena

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

Re: [Talk-it] building:levels

[scratera]

https://wiki.openstreetmap.org/wiki/Key:building:levels
...personalmente per mè il livello 0 è il livello del suolo...casa con
appartamento solo al piano terra  building:levels=1



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

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

[Talk-it] building:levels

[Jeawrong]

Salve, mi è sorto un dubbio riguardo al tag in questione: nelle pagine del
wiki (sia italiana che inglese) si legge che "Il tag building:levels è usato
per indicare i piani sopraelevati di un edificio", ("The building:levels tag
is used for marking the number of above-ground levels" nella pagina inglese)
quindi il piano terra è 0, il primo piano è 1, insomma la classica
definizione che si trova anche sulle pulsantiere degli ascensori. Il disegno
esemplificativo però indica tutt'altro, come se il piano terra sia da
considerare piano 1. Forse si tratta solo di un malinteso tra il disegno e
quanto scritto, ma se io entro in un pian terreno non entro in alcunchè di
sopraelevato rispetto al piano stradale. Qual'è il modo corretto dunque?



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

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

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 105, Udgave 7

[Uffe Kousgaard]

DAGI:
http://sdfe.dk/hent-data/danmarks-administrative-graenser-dagi/

On 17-04-2018 16:21, Anders Lund wrote:


Det lyder som en god ide! Findes de mon ikke i en frit tilgængelig kilde?




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

Re: [Talk-it] Elisuperficie

[paolo bubici]

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlanding_site


Il Mar 17 Apr 2018, 16:27 riccardopastoc...@alice.it <
riccardopastoc...@alice.it> ha scritto:

> Due cose:
>
> a) Mi controllate se ho mappato bene questa area per elisuperfice?
> https://www.openstreetmap.org/#map=19/43.36763/13.58621
>
>
> b) Come posso mappare aree dove l'elicottero del 118 atterrà di solito?
> E distinguerla da una elisuperfice?
> Per capirci:  non è una piazzola per eliambulanza, ma un punto specifico
> dove l'elicottero atterra in mancanza di meglio.
>
>
> Esempio area verde antistante Itis Mattei di Recanati
> https://www.openstreetmap.org/#map=19/43.40153/13.55804
>
>
> Grazie
> Riccardo
> ___
> 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] GDPR introduction

[Ed Loach]

Andrew asked:

> Yes that does help clarify my concerns too. I still wonder if someone 
> outside the EU can go ahead and publish the full metadata included 
> OSM database under the ODBL outside the OSMF, or in the worst case 
> local communities outside the EU can still publish their regional extracts 
> with metadata publicly.

I am not a lawyer, but a quick Google search suggests the answer is no, as the 
legislation applies based on the data subject being in the EU, not the 
processor - see for example "Why non-EU companies should care" in 
https://econsultancy.com/blog/69282-how-should-non-eu-businesses-prepare-for-the-gdpr

Ed


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

[Talk-it] Elisuperficie

[riccardopastoc...@alice.it]

Due cose:
a) Mi controllate se ho mappato bene questa area per 
elisuperfice?https://www.openstreetmap.org/#map=19/43.36763/13.58621

b) Come posso mappare aree dove l'elicottero del 118 atterrà di solito?E 
distinguerla da una elisuperfice?Per capirci:  non è una piazzola per 
eliambulanza, ma un punto specifico dove l'elicottero atterra in mancanza di 
meglio.

Esempio area verde antistante Itis Mattei di 
Recanatihttps://www.openstreetmap.org/#map=19/43.40153/13.55804 

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

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 105, Udgave 7

[Anders Lund]

tirsdag den 17. april 2018 10.19.39 CEST skrev Jørgen Elgaard Larsen:
> Anders Lund skrev:
> > Alle de pokkers små flækker ødelægger stedsøgningen (reverse geosearch fx
> > på osm.org) fra et bruger-synspunkt. Søgning efter adresser i danmark
> > giver ret absurde resulater, fordi flækkerne er punkter, og der ingen
> > regler er for hornår de er relevante.
> 
> Jeg vil mene, at de absurde resultater primært skyldes, at
> adressesøgningerne (begge veje) som regel ignorerer Karlsruhe-skemaet og
> udelukkende baserer sig på is-in.
> 
> Det er især et problem i Danmark, hvor vi følger Karlsruhe, men ikke har
> postnummer-områder i vores kort. De fleste adresse-søgestjenester går i
> panik, når en adresse ikke ligger i et postnummer-område. Så vælger de
> et place i nærheden.
> 
> Vi har tidligere talt om at lægge danske postnummer-områder ind i kortet
> - det ville hjælpe en del på adressesøgning.

Det lyder som en god ide! Findes de mon ikke i en frit tilgængelig kilde?

> - Jørgen
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk





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

Re: [OSM-talk] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Andrew Harvey wrote:
>
> Yes that does help clarify my concerns too. I still wonder if someone
> outside the EU can go ahead and publish the full metadata included
> OSM database under the ODBL outside the OSMF, or in the worst case
> local communities outside the EU can still publish their regional
> extracts with metadata publicly.

Well - that is obviously a question you need to get qualified local 
legal advise on.  Same as if you can publicly distribute a copy of 
.

-- 
Christoph Hormann
http://www.imagico.de/

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

[Talk-dk] FW: autoAWS første udkast

[Jakob Barfod]

Til Søren Johannesen / Neogeografen, cc:OSM talk-dk.

Hej Søren.

Undskyld, jeg sådan trænger mig på, men du har tidligere været aktiv på din
blog "microformats", som p.t. ikke er tilgængelig.

Som du kan se herunder, er der på OSM's talk-dk-postliste en længere
diskussion i gang vedr. automatisk import og opdatering af danske adresser
fra Det Danske Adresseregister til erstatning for AWSbot.

Men hvordan er det nu? På din blog har du tidligere nævnt et projekt om
oprydning i de danske gadenavne
(http://www.microformats.dk/2012/01/12/helt-sk%c3%a6v-i-sk%c3%a6vinge/) -
men det var tilbage i 2012(!)

Fra din blog:

"Der kører et prestige projekt i OpenStreetMap Danmark, som går ud på at
blive det første online kort i Danmark, som bruger korrekt retstavning for
vejnavnene. Dvs at forkortelser som fx Gl, Sdr, Ndr, Nr, Dr, Kvt osv.
forsvinder og i stedet for skrives de fuldt ud (Dr bliver så til Dronning
eller Doktor) samt at personnavne i vejnavnene skrives mere korrekt end hvad
offentlige myndigheder gør det pt. fx “Chr Winthersvej” bliver til det mere
korrekte “Christian Winthers Vej”."

Kan du huske noget om, hvor projektet er dokumenteret?

Venligst,

-- 
Jakob

-Original Message-
From: Niels Elgaard Larsen [mailto:elga...@agol.dk] 
Sent: 17. april 2018 14:19
To: talk-dk@openstreetmap.org
Subject: Re: [Talk-dk] autoAWS første udkast

On Tue, 17 Apr 2018 11:13:12 +0200
Jonathan Hougaard  wrote:


> Mht. 4 - som nævnt tidligere, er min tilgang generelt (nødt til at 
> være), at data fra DAR er korrekt.

Men det er data fra DAR altså ikke altid. Datakvaliteten er høj, men det er
ikke perfekt.

> Jeg har ikke deltaget i den nævnte
> diskussion, og kender derfor ikke argumenterne. Teknisk kan jeg godt, 
> hvis der er konsensus om det, rette forkortede vejnavne til deres 
> fulde navn før de importeres. Dette kræver, at der er en eller anden, 
> der laver en komplet liste med forkortelser og deres udvidede form 
> (Dr. = Doktor, Nr. = Nørre osv.)

Men er dit system så smart nok til at vide at "Dr. Dorothea" er Dronning
Dorothea og ikke Doktor Dorothea?

> Umiddelbart har jeg lidt svært ved at forstå, hvorfor vi ønsker at 
> ændre de tilsyneladende officielle vejnavne fra DAR,

Fordi de ikke er korrekte. Og de er heller ikke officielle. Det er bare en
database. Mange af fejlene i DAR skyldes at vejnavnene oprindeligt er
indtastet i et system, hvor der kun var plads til 20 tegn for vejnavne. Det
gør ikke Borgm.Jespersensvej til et officielt vejnavn, så kommunen kører ud
og skifter alle skiltene.

Det ser ud til at de fleste fixes på OIS-fixes nu er rettet i DAR, (fx
Tengslemrk Strandvej => Tengslemark Strandvej).

Men der var jo så et stykke tid hvor navnene var korrekte i OSM, men endnu
ikke rettet i DAR/AWS. Og måske har de rettet det fordi de så rettelsen i
OSM. Under alle omstændigheder kommer der sikkert nye veje med fejl i DAR,
som de vil være lang til om at rette.


> men som sagt
> kender jeg ikke argumenterne.


> Mht. position, som tidligere diskuteret et sted i forrige tråd, bør 
> fejl rettes direkte hos DAR.

Igen, der kan gå lang tid inden vi får rettet fejl i DAR.
Og hvis vi ved at data i OSM er forkerte, skal der være en måde at rette dem
i OSM indtil de bliver rettet i DAR.

> Hvis der er helt exceptionelle tilfælde hvor en adresseknude i OSM 
> ikke skal placeres på den officielle placering (jeg kan ikke 
> umiddelbart komme på nogen!),

https://overpass-turbo.eu/s/xYk
Mange af dem er rettet i DAR, så vi burde gå dem igennem og rydde op.

Men der er stadig mærkelige ting i DAR.

Fx at der både er Gl. Strandvej 237 i Humlebæk og Gammel Strandvej 237 i
Espergærde.

>  kan vi
> eventuelt anvende et specielt tag, så knuden bliver ignoreret 
> (autoaws=ignore eller hvad ved jeg). Så vidt jeg forstår, har AWSbot 
> haft en tilsvarende funktion.

Vi kan vel fortsætte med ois:fixme
 
> On 17/04/2018 10:26, Jakob Barfod wrote:
> >> I må meget gerne kigge beskrivelsen igennem og komme med forslag og 
> >> kommentarer til dette.
> > 1. Rigtig godt arbejde!
> >
> > 2. Foretrækker du, at diskussion foregåer her på talk-dk eller på 
> > diskussionssiden på wiki'en? 2.a. Hvis her på talk-dk, så opretter 
> > jeg lige en henvisning på wiki'en.
> >
> > 3. Henvisninger til AWSbot på diverse wiki-sider bør opdateres, så 
> > AutoAWS nævnes i stedet. Ikke ment sådan, at _du_ skal gøre det, men 
> > hermed efterlyses steder, hvor vi bør opdatere diverse tekster.
> > Fx... 3.a https://wiki.openstreetmap.org/wiki/Addresses#Denmark 3.b 
> > https://www.openstreetmap.org/user/AWSbot 3.c 
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue/KMS 3.d Flere?
> >
> > 4. Konfliktende opdateringer? Hvem har ret, DAR eller OSM?
> > Jf. den gamle "Dr. Tværgade<>Doktor Tværgade"-diskussion, så lægger 
> > jeg mærke til, at stavningen fra DAR bruges, hvis der er forskel:
> >
> > "Any one of the following conditions will trigger an update:
> > [...]
> > The position (lat and lon) of the 

Re: [Talk-dk] autoAWS første udkast

[Jakob Barfod]

> > Mht. position, som tidligere diskuteret et sted i forrige tråd, bør
> > fejl rettes direkte hos DAR.
> 
> Igen, der kan gå lang tid inden vi får rettet fejl i DAR.
> Og hvis vi ved at data i OSM er forkerte, skal der være en måde at rette
> dem i OSM indtil de bliver rettet i DAR.

Bemærk følgende fra https://wiki.openstreetmap.org/wiki/Da:Adresser :

  "osak:street_name=* er kun benyttet i tilfælde hvor der er blevet oprettet en 
automatisk rettelse af vejnavne via OIS-fixes siden. Tagget vil da indeholde 
det oprindelige vejnavn som angivet i OIS hvorimod addr:street=* vil indeholde 
det korrekte vejnavn.

Så husk ikke at ændre i osak:street_name=* for ellers kan botten ikke finde ud 
af det og importere adressen 2 gange."

Det giver god mening...

-- 
Jakob


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

Re: [OSM-talk] GDPR introduction

[Andrew Harvey]

On 17 April 2018 at 23:31, Christoph Hormann  wrote:

> On Tuesday 17 April 2018, Simon Poole wrote:
> >
> > > * When you add new 'terms of use' or 'data processing agreement'
> > > provisions that people who want to access OSM data with metadata
> > > need to agree to does that constitute an amendment of the ODbL and
> > > therefore a change in license?  If not would any downstream data
> > > user who distributes a derivative database be allowed to add
> > > similar terms of use that restrict use of the data to the data they
> > > distribute?
> >
> > As the mail said, the exact details are not nailed down there yet,
> > however it is likely that we will not want to enter in to an
> > agreement with such people, but would simply offer to help with their
> > obligations from Art. 14. It is not as if the GDPR suddenly
> > disappears when we distribute data on ODbL terms so people processing
> > the full dataset are going to be subject to it in any case.
>
> Ok - that is much clearer (and IMO also addresses what Andrew wondered
> about).  If it is sufficient for the GDPR to (a) not have technically
> unrestricted access and (b) make sure everyone receiving the data is
> made aware of the legal obligations that seems something that can be
> reasonably dealt with.
>
> The terminology used in the position paper however seems to point into a
> somewhat different direction (i.e. that providing bulk metadata would
> be subject to a specific contractual agreement).


Yes that does help clarify my concerns too. I still wonder if someone
outside the EU can go ahead and publish the full metadata included OSM
database under the ODBL outside the OSMF, or in the worst case local
communities outside the EU can still publish their regional extracts with
metadata publicly.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Cascafico Giovanni]

Puoi scegliere "browse points" e poi "edit this".

Il 17 apr 2018 3:25 PM, "Damjan Gerl"  ha scritto:

Ciao!
Ma posso validare i punti che conosco? Io non ci riesco. Sceglie da solo i
punti da validare.

D.


-- Original Header ---

>From  : "Cascafico Giovanni" cascaf...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  :
Date  : Tue, 17 Apr 2018 14:31:51 +0200
Subject : [Talk-it] [ItalyFuelStations] revisione pre-import

> La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
> (includendo anche i waterway=fuel).
> Nella procedura di import è successivamente previsto un "audit"
(revisione)
> dei risultati, come illustrato in questo [1] schema.
>
> A mio parere non è necesario validare tutti i 20709 nodi per proseguire
> nell'import, ma la revisione della comunità è comunque un passo
importante.
>
> Effettuare una revisione collaborativa è abbastamza semplice: si va alla
> pagina del progetto di audit [2].
>
> __
>
> SEGNAPOSTO AZZURRI:
> distributori già presenti in OSM. Si potrà scegliere:
>
> - fixme (opzionale)
> una breve nota dei problemi (per esempio il distributore in OSM è spostato
> rispetto immagine aerea)
>
> - Good
> si accettano le modifiche dei tag evidenziati in verde, mentre la
posizione
> rimane invariata
>
> - Don't change
> non fa niente e passa al prossimo
>
> - Skip
> esclude il record del MISE dall'import
>
> SEGNAPOSTO VERDI:
> distributori non presenti in OSM. Si potrà scegliere:
>
> - fixme (opzionale)
> una breve nota dei problemi
>
> - Good
> inseriti nella posizione e con in tag elencati
>
> - Duplicate
> segnala già presente (non intercettato dalla conflation perchè fuori dal
> raggio impostato)
>
> - Not there
> non si vede in giro
>
> - Skip
> esclude il recod del MISE dall'import
> __
>
> Queste validazioni hanno come unico scopo generare un file audit.json da
> applicare al secondo passo della conflation e produrre il file .osm pronto
> per l'upload.
>
>
>
>
> [1]
> https://wiki.openstreetmap.org/w/images/thumb/f/fe/
Conflate_audit_chart.jpg/800px-Conflate_audit_chart.jpg
> [2] http://audit.osmz.ru/project/IFS
>

___
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] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Simon Poole wrote:
>
> > * When you add new 'terms of use' or 'data processing agreement'
> > provisions that people who want to access OSM data with metadata
> > need to agree to does that constitute an amendment of the ODbL and
> > therefore a change in license?  If not would any downstream data
> > user who distributes a derivative database be allowed to add
> > similar terms of use that restrict use of the data to the data they
> > distribute?
>
> As the mail said, the exact details are not nailed down there yet,
> however it is likely that we will not want to enter in to an
> agreement with such people, but would simply offer to help with their
> obligations from Art. 14. It is not as if the GDPR suddenly
> disappears when we distribute data on ODbL terms so people processing
> the full dataset are going to be subject to it in any case.

Ok - that is much clearer (and IMO also addresses what Andrew wondered 
about).  If it is sufficient for the GDPR to (a) not have technically 
unrestricted access and (b) make sure everyone receiving the data is 
made aware of the legal obligations that seems something that can be 
reasonably dealt with.

The terminology used in the position paper however seems to point into a 
somewhat different direction (i.e. that providing bulk metadata would 
be subject to a specific contractual agreement).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Damjan Gerl]

Ciao!
Ma posso validare i punti che conosco? Io non ci riesco. Sceglie da solo i 
punti da validare.

D.


-- Original Header ---

From  : "Cascafico Giovanni" cascaf...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Tue, 17 Apr 2018 14:31:51 +0200
Subject : [Talk-it] [ItalyFuelStations] revisione pre-import

> La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
> (includendo anche i waterway=fuel).
> Nella procedura di import è successivamente previsto un "audit" (revisione)
> dei risultati, come illustrato in questo [1] schema.
> 
> A mio parere non è necesario validare tutti i 20709 nodi per proseguire
> nell'import, ma la revisione della comunità è comunque un passo importante.
> 
> Effettuare una revisione collaborativa è abbastamza semplice: si va alla
> pagina del progetto di audit [2].
> 
> __
> 
> SEGNAPOSTO AZZURRI:
> distributori già presenti in OSM. Si potrà scegliere:
> 
> - fixme (opzionale)
> una breve nota dei problemi (per esempio il distributore in OSM è spostato
> rispetto immagine aerea)
> 
> - Good
> si accettano le modifiche dei tag evidenziati in verde, mentre la posizione
> rimane invariata
> 
> - Don't change
> non fa niente e passa al prossimo
> 
> - Skip
> esclude il record del MISE dall'import
> 
> SEGNAPOSTO VERDI:
> distributori non presenti in OSM. Si potrà scegliere:
> 
> - fixme (opzionale)
> una breve nota dei problemi
> 
> - Good
> inseriti nella posizione e con in tag elencati
> 
> - Duplicate
> segnala già presente (non intercettato dalla conflation perchè fuori dal
> raggio impostato)
> 
> - Not there
> non si vede in giro
> 
> - Skip
> esclude il recod del MISE dall'import
> __
> 
> Queste validazioni hanno come unico scopo generare un file audit.json da
> applicare al secondo passo della conflation e produrre il file .osm pronto
> per l'upload.
> 
> 
> 
> 
> [1]
> https://wiki.openstreetmap.org/w/images/thumb/f/fe/Conflate_audit_chart.jpg/800px-Conflate_audit_chart.jpg
> [2] http://audit.osmz.ru/project/IFS
> 

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

Re: [OSM-talk-fr] Un nouveau 'concurrent' ?

[Philippe Verdy]

Concernant Mapcat.com, je trouve que leur rendu vectoriel est beaucoup trop
agressif sur les simplications géométriques, ce qui donne des polygones
beaucoup trop anguleux par rapport aux données (il suffit de voir le tracé
des rocades ou des courbes de lignes de chemin de fer), et trop souvent des
intersections fausses entre polygones qui en fait ne se croisent même pas
dans les données, et dans certains cas où les polygones ont de fortes
concavités (exemple lacs ou forêt)s, des autointersections sur la forme
"simplifiée" et un rendu complètement faux.

L'algo de simplification ne semble pas tenir compte de la structure du
"squelette" pour le conserver ou au moins pour ne pas en altérer la
topologie (peut être admis cependant l'élimination de certaines branches
courtes du squelette). Note: le "squelette" est la structure géométrique
duale qu'on obtient par réduction d'une triangulation optimale d'une
surface polygonale quelconque même quand elle est concave ou comporte des
trous: s'il y a des trous ce squelette contiendra éventuellement des
anneaux fermés autour, non nécessairement reliés au reste du squelette si
le trou est assez petit et pas trop proche du contour externe de la surface
où il est situé; une simplification géométrique pour un rendu convenable
peut éliminer ces anneaux du squelette si leur taille est assez faible
(mesurée comme la surface de l'ellipse inscrite sur la paire de points les
plus proches et la paire la plus éloignée du contour dépasse un seuil
proportionnel à la surface des pixels du rendu soit environ une dizaine de
pixels-carrés), et alors permettre d'éliminer du contour simplifié de la
surface décrite certains segments trop courts (moins de 4 pixels de
longueur).

Mais là sur Mapcat.com, les simplifications semblent ne pas tenir compte du
tout de la géométrie (squelette, angles ou courbes) et se contentent juste
de fixer un seuil de distance minimale entre deux points du contour
simplifié, et ça donne trop d'aberrations visibles, et pour certaines
simplifications, au lieu d'éliminer des sommets uniquement on devrait
pouvoir réduire l'erreur en remplaçant certains d'entre eux par une
interpolation sur une courbe spline (au moins du deuxième degré, mais une
cubique sera sans doute meilleure) pour un rendu bien meilleur des courbes
par un polygone formé (autre solution: générer non pas un polygone mais un
spline: la simplificaton ne garde pas que des sommets mais détermine des
points de contrôle entre deux sommets (tout en évitant les aberrations
comme les autointersections modifiant le squelette: si c'est le cas,
réduire le degré pour garder moins de points de contrôle).

Je ne sais pas si des travaux existent sur les techniques de simplification
géométriques de surfaces polygonales: pour le rendu de cartes vectorielles
à haute densité comme OSM (et notamment pour les faibles niveaux de zoom),
c'est un facteur important (rien que le calcul du squelette prend un temps
considérable, mais il est facilement parallélisable, et un GPU peut aider
beaucoup à accélérer ça avec ses nombreux coeurs pour traiter une
triangulation très dense avec des volumes de données importants)


Le 17 avril 2018 à 12:55, Vincent Frison  a écrit
:

> Le 16 avril 2018 à 11:39, Cédric Frayssinet  a
> écrit :
>
>>
>> Merci Noémie pour ces précisions !
>>
>> Qwant étant un moteur de recherche, est-il prévu également d'améliorer le
>> moteur actuel d'OpenStreetMap qui est pour moi le point faible autant sur
>> OpenStreetMap.org que sur OsmAnd. En effet, une seule petite lettre en
>> défaut et on n'obtient aucun résultat :( C'est une des grosses forces de
>> GMaps pour le coup...
>>
>> Sur Mastodon, on m'a dit que ce serait chouette de se rapprocher de cette
>> interface : https://en.mapy.cz/ et moi je rajoute celle-ci :
>> https://maps.mapcat.com/
>>
>
> Je trouve Mapy.cz impressionnant, pour moi c'est peut-être la meilleure
> webmap basée sur OSM ! Elle a quasiment tout, il manque juste la
> possibilité de voir l'ensemble des données comme sur osm.org (par ex.
> certains commerces ou restaurant ne sont pas visibles, même avec la carte
> "touriste"). Bref merci pour le lien...
>
> Pour revenir au sujet j'ai vraiment hâte de voir ce que Qwant va nous
> proposer, c'est pas tous les jours qu'une "grosse" boite fait une solution
> cartographique pour le grand public basée sur OSM...
>
> ++ Vincent
>
>
> ___
> 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] GDPR introduction

[Andrew Harvey]

Thank you those in the LWG that have put this paper together. My thoughts
are OSM's ODBL license grants me the right to publish a version of
http://hdyc.neis-one.org/ open to the public, not restricted to OSM users.
Reading this, I understand the OSMF is proposing to introduce Terms of Use
which take away my rights to use the OpenStreetMap data in ways that were
okay last month, in order to comply with an EU specific law. Would that
eliminate all options for someone outside the EU to publish something like
http://hdyc.neis-one.org/ but open to the public?

On 17 April 2018 at 20:48, Simon Poole  wrote:

> On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
> * will
> enter in to force, this will likely result in some changes in how
> OpenStreetMap operates and distributes its data.
>
> The LWG has prepared a position paper on the matter that has been reviewed
> by data protection experts and in general the approach to not rely on
> explicit consent has been validated. It should be noted that while the
> paper outlines our approach, some of the details still need to be
> determined. In particular the future relationship with community and third
> party data consumers that utilize OSM meta-data and what will actually be
> dropped/made less accessible of the data listed in Appendix B.
>
> LWG GDPR Position Paper
> 
>
> Please feel free to discuss on the talk page
>  or on this list.
>
> Simon
>
> ___
> 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-ja] 高速道路の定義について

[Ras and Road]

Ras and Roadです。

まずは、hayashiさんの4月15日01:32の投稿へのレスポンスです。
hayashiさんが
> 上記のことから、「自動車専用道路」は「国で最高品質の道路」とみなすことができるといえます。
と言及されているのは *提案1 乃至は *提案1-1 についてですよね？
*提案3-1　motorroad=yesの定義を「自動車専用道路」標識がついた道路とする
の解釈に関して、「自動車専用道路の標識がなくとも『歩行者、軽車両、原付、小型二輪』が通行できなければ『自動車専用道路』とみなす」なら、通行制限の結果に変わりがないので反対はしないのですが。

あまのさんの3/29投稿のとおり、自動車専用道路は道路法第48条の2に定められるとおり、「市街地の交通の円滑化」「特定の道路の区間内の交通円滑化/道路交通騒音により生じる障害の防止」という目的で指定されるものです。
もしかすると、「国で最高品質の道路（原文：to identify the highest-performance roads within
a territory）」の“品質(performance)”の理解がこのスレッドに参加している人の間ですれ違っているのでしょうか？
私は、国土骨格やネットワークや産業基盤に資するかどうかが“品質(performance)”だと理解しています。


次に、hayashiさん/muramotoさん両名へのレスポンスです。
私も机上での検証可能性が判断条件だとは思いません。しかし、机上で検証する方法がない・難しいことを理解したうえで賛否を取るべきと考えた次第です。
マッパーがもっと増えれば、それぞれの得意地域（気軽に現調できる地域）でマッパー相互に検証できるでしょうが、まだそんな状態ではないと思います。

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

Re: [OSM-talk] GDPR introduction

[Simon Poole]

Am 17.04.2018 um 14:14 schrieb Christoph Hormann:
> On Tuesday 17 April 2018, Simon Poole wrote:
>
>> LWG GDPR Position Paper
>> 
>>
>> Please feel free to discuss on the talk page
>>  or on this list.
> A number of questions/comments:
>
> * Is there some sort of document outlining the data retention practice 
> for user logins on the OSM website which according to your suggestion 
> would be the basis of granting access to metadata in the future.  
> Obviously some level of retention of such data is permitted (for abuse 
> prevention etc.) but it would be nice to know how long and in what form 
> such data is retained.  This is not directly related to the GDPR but 
> would become increasingly relevant if functionality on the OSM website 
> is more often subject to being logged in.
Currently there is no formal policy on how long the logs for
openstreetmap.org are retained as far as I know, but it is one of the
things that should be documented.
>
> * I am not completely sure about the view of the LWG regarding the 
> question if the geodata itself (that is geometries, tags and IDs of 
> nodes, ways and relations) contains personal data according to the 
> GDPR.  Your recommendations seem to indicate you think it does not but 
> that is not necessarily self-evident.  Note i am not talking about 
> special cases here where mappers add personal data (like names of 
> people living in a house) although they should not, i am talking about 
> normally mapped stuff where you could identify individual mappers from 
> tagging and geometry characteristics and based on timing derived from 
> feature IDs.
We don't have a formal view on the pure geographic data itself, but are
naturally aware that taken to extremes it could be analysed the way you
suggest.
>
> * When you add new 'terms of use' or 'data processing agreement' 
> provisions that people who want to access OSM data with metadata need 
> to agree to does that constitute an amendment of the ODbL and therefore 
> a change in license?  If not would any downstream data user who 
> distributes a derivative database be allowed to add similar terms of 
> use that restrict use of the data to the data they distribute?
As the mail said, the exact details are not nailed down there yet,
however it is likely that we will not want to enter in to an agreement
with such people, but would simply offer to help with their obligations
from Art. 14. It is not as if the GDPR suddenly disappears when we
distribute data on ODbL terms so people processing the full dataset are
going to be subject to it in any case.

>
> * Your position paper does not seem to mention the OAuth service - it 
> seems to me registering an application to use this in the current form 
> would also need to require a special agreement.  In addition it might 
> be a good idea (i think i suggested this already in the past) to 
> provide an anonymous OAuth service - where the application using it 
> gets confirmation that the user is logged in as an registered OSM user 
> but which does not provide any information on this user's identity.
>
Well such an app can only access the data of the user that authorized
its access and even so not anything particularly critical (for example
it currently doesn't have access to the e-mail address), but it is clear
that there is opportunity for harvesting some data there. But in any
case this is more a question of if we want to validate apps in general
that access OSM or not, which in turn would imply blocking non-validated
ones and so on..

Simon



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

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Il giorno 17 aprile 2018 14:16, Andrea Musuruane  ha
scritto:

> Giocando con awk e grep (la sintassi della regexp è leggermente
> differente) si possono vedere i valori che vengono estratti:
> awk -F ";" '{print $6}' anagrafica_impianti_attivi.csv | grep -E
> '.*,*[[:blank:]]+([[:digit:]]+\/*[[:alnum:]]*),*[[:blank:]]+
> ([[:digit:]]{5})'
>
> e quelli che vengono scartati:
> awk -F ";" '{print $6}' anagrafica_impianti_attivi.csv | grep *-v* -E
> '.*,*[[:blank:]]+([[:digit:]]+\/*[[:alnum:]]*),*[[:blank:]]+([[:digit:]]{5})'
>
>
> I falsi positivi sono proprio pochi (la regola cerca di scartare tutti gli
> indirizzi che non hanno numero civico e cap), soprattutto considerando il
> marasma che c'è nei dati sorgente.
>

E' con malcelata invidia che applaudo Andrea, ora meglio noto come Gran
Visir delle regexp :-) Mi son permesso di contare le linee generate dai due
comandi e vien fuori che 10960 sono "indirizzabili", contro le 9940
incasinate.
Credo che al primo aggiornamento post-import ci metteremo pure gli addr!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] [ItalyFuelStations] revisione pre-import

[Cascafico Giovanni]

La conflation del dataset MISE è stata eseguita con i dati del 2018-04-16
(includendo anche i waterway=fuel).
Nella procedura di import è successivamente previsto un "audit" (revisione)
dei risultati, come illustrato in questo [1] schema.

A mio parere non è necesario validare tutti i 20709 nodi per proseguire
nell'import, ma la revisione della comunità è comunque un passo importante.

Effettuare una revisione collaborativa è abbastamza semplice: si va alla
pagina del progetto di audit [2].

__

SEGNAPOSTO AZZURRI:
distributori già presenti in OSM. Si potrà scegliere:

- fixme (opzionale)
una breve nota dei problemi (per esempio il distributore in OSM è spostato
rispetto immagine aerea)

- Good
si accettano le modifiche dei tag evidenziati in verde, mentre la posizione
rimane invariata

- Don't change
non fa niente e passa al prossimo

- Skip
esclude il record del MISE dall'import

SEGNAPOSTO VERDI:
distributori non presenti in OSM. Si potrà scegliere:

- fixme (opzionale)
una breve nota dei problemi

- Good
inseriti nella posizione e con in tag elencati

- Duplicate
segnala già presente (non intercettato dalla conflation perchè fuori dal
raggio impostato)

- Not there
non si vede in giro

- Skip
esclude il recod del MISE dall'import
__

Queste validazioni hanno come unico scopo generare un file audit.json da
applicare al secondo passo della conflation e produrre il file .osm pronto
per l'upload.




[1]
https://wiki.openstreetmap.org/w/images/thumb/f/fe/Conflate_audit_chart.jpg/800px-Conflate_audit_chart.jpg
[2] http://audit.osmz.ru/project/IFS
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 16. Apr 2018, at 13:26, Cascafico Giovanni  wrote:
> 
> i nodi sono più di 20.000 ed una verifica e correzione a tappeto sarebbe 
> difficilmente completabile.


non abbiamo fretta, possiamo caricare i POI successivamente quando li abbiamo 
verificati (non devono prima essere verificati 2 e poi caricati 2, 
possiamo anche prendere 100, e poi altri 100, finché abbiamo fatto 200 volte 
100). Se nel frattempo arriva l’aggiornamento del dataset continueremmo con 
questo. È sicuro che arriva l’aggiornamento, vogliamo ogni volta sovrascrivere 
i nostri dati con quelli del db MISE?

Io penso dobbiamo vedere questo più come un’attività continua che come un 
import ogni tanto.

Stavi parlando di 2 nodi con differenze significative, o sono tutti i nodi?


Ciao, Martin 


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

Re: [Talk-dk] autoAWS første udkast

[Niels Elgaard Larsen]

On Tue, 17 Apr 2018 11:13:12 +0200
Jonathan Hougaard  wrote:


> Mht. 4 - som nævnt tidligere, er min tilgang generelt (nødt til at 
> være), at data fra DAR er korrekt.

Men det er data fra DAR altså ikke altid. Datakvaliteten er høj, men
det er ikke perfekt.

> Jeg har ikke deltaget i den nævnte 
> diskussion, og kender derfor ikke argumenterne. Teknisk kan jeg godt, 
> hvis der er konsensus om det, rette forkortede vejnavne til deres
> fulde navn før de importeres. Dette kræver, at der er en eller anden,
> der laver en komplet liste med forkortelser og deres udvidede form
> (Dr. = Doktor, Nr. = Nørre osv.)

Men er dit system så smart nok til at vide at "Dr. Dorothea" er Dronning
Dorothea og ikke Doktor Dorothea?

> Umiddelbart har jeg lidt svært ved at forstå, hvorfor vi ønsker at
> ændre de tilsyneladende officielle vejnavne fra DAR,

Fordi de ikke er korrekte. Og de er heller ikke officielle. Det er bare
en database. Mange af fejlene i DAR skyldes at vejnavnene oprindeligt
er indtastet i et system, hvor der kun var plads til 20 tegn for
vejnavne. Det gør ikke Borgm.Jespersensvej til et officielt vejnavn, så
kommunen kører ud og skifter alle skiltene.

Det ser ud til at de fleste fixes på OIS-fixes nu er rettet i
DAR, (fx Tengslemrk Strandvej => Tengslemark Strandvej).

Men der var jo så et stykke tid hvor navnene var korrekte i OSM, men
endnu ikke rettet i DAR/AWS. Og måske har de rettet det fordi de så
rettelsen i OSM. Under alle omstændigheder kommer der sikkert nye veje
med fejl i DAR, som de vil være lang til om at rette.


> men som sagt
> kender jeg ikke argumenterne.


> Mht. position, som tidligere diskuteret et sted i forrige tråd, bør
> fejl rettes direkte hos DAR. 

Igen, der kan gå lang tid inden vi får rettet fejl i DAR.
Og hvis vi ved at data i OSM er forkerte, skal der være en måde at
rette dem i OSM indtil de bliver rettet i DAR.

> Hvis der er helt exceptionelle tilfælde
> hvor en adresseknude i OSM ikke skal placeres på den officielle
> placering (jeg kan ikke umiddelbart komme på nogen!),

https://overpass-turbo.eu/s/xYk
Mange af dem er rettet i DAR, så vi burde gå dem igennem og rydde op.

Men der er stadig mærkelige ting i DAR.

Fx at der både er Gl. Strandvej 237 i Humlebæk og Gammel Strandvej 237 i
Espergærde.

>  kan vi
> eventuelt anvende et specielt tag, så knuden bliver ignoreret
> (autoaws=ignore eller hvad ved jeg). Så vidt jeg forstår, har AWSbot
> haft en tilsvarende funktion.

Vi kan vel fortsætte med ois:fixme
 
> On 17/04/2018 10:26, Jakob Barfod wrote:
> >> I må meget gerne kigge beskrivelsen igennem og komme med forslag og
> >> kommentarer til dette.  
> > 1. Rigtig godt arbejde!
> >
> > 2. Foretrækker du, at diskussion foregåer her på talk-dk eller på
> > diskussionssiden på wiki'en? 2.a. Hvis her på talk-dk, så opretter
> > jeg lige en henvisning på wiki'en.
> >
> > 3. Henvisninger til AWSbot på diverse wiki-sider bør opdateres, så
> > AutoAWS nævnes i stedet. Ikke ment sådan, at _du_ skal gøre det,
> > men hermed efterlyses steder, hvor vi bør opdatere diverse tekster.
> > Fx... 3.a https://wiki.openstreetmap.org/wiki/Addresses#Denmark 3.b
> > https://www.openstreetmap.org/user/AWSbot 3.c
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue/KMS 3.d Flere?
> >
> > 4. Konfliktende opdateringer? Hvem har ret, DAR eller OSM?
> > Jf. den gamle "Dr. Tværgade<>Doktor Tværgade"-diskussion, så lægger
> > jeg mærke til, at stavningen fra DAR bruges, hvis der er forskel:
> >
> > "Any one of the following conditions will trigger an update:
> > [...]
> > The position (lat and lon) of the node is not equal to the AWS
> > address position addr:street=* is not equal to the AWS street name "
> >
> > Er det hensigtsmæssigt? Hvad nu hvis en OSM-bruger har tilrettet
> > forkerte data (fx position eller stavning af vejnavn)? Det kan jeg
> > simpelthen ikke gennemskue. 
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk



-- 
Niels

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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao,

2018-04-17 10:51 GMT+02:00 Cascafico Giovanni :

> Il giorno 28 marzo 2018 11:46, Andrea Musuruane  ha
> scritto:
>
>> Nel file description viene messo l'indirizzo. Sarebbe meglio riuscire a
 metterlo in addr:street e addr:housenumber (per quelli che hanno un numero
 civico, per gli altri l'informazione mi sembra inutile).

>>>
>>> Onestamente non saprei come processare la stringa... l'unica certezza di
>>> questo campo è il codice postale alla fine. La ho assegnata a description,
>>> pensando che il mappatore occasionale possa eventualemnte aggiungere il
>>> civico manualmente. Anche il no rari riferimenti kilometrici (p.es. "Ss
>>> 356 Km 45+5112") potrebbero essere utili per mettere qualche milestone,
>>> seppure mi pare siano relegate ad ogetti historic.
>>>
>>
>> Si può fare in questo modo.
>>
>> Estrai tre valori dalla stringa in base alla seguente espressione
>> regolare:
>> (.*),*\s+(\d+\/*\w*),*\s+(\d{5})
>>
>> Se l'espressione regolare non è soddisfatta si scarta la stringa.
>>
>
> Ho applicato al regexp in qgis (necessario anteporre un ulteriore
> backslash ad ogni backslash)
> regexp_substr ("Indirizzo", '(.*),*\\s+(\\d+\\/*\w*),*\s+(\\d{5})' )
>
> ed estrae il nome strada per circa metà dei record. Speriamo che il modulo
> online che il MISE sta pubblicando per i gestori ci semplichi la vita :-)
>

Giocando con awk e grep (la sintassi della regexp è leggermente differente)
si possono vedere i valori che vengono estratti:
awk -F ";" '{print $6}' anagrafica_impianti_attivi.csv | grep -E
'.*,*[[:blank:]]+([[:digit:]]+\/*[[:alnum:]]*),*[[:blank:]]+([[:digit:]]{5})'

e quelli che vengono scartati:
awk -F ";" '{print $6}' anagrafica_impianti_attivi.csv | grep *-v* -E
'.*,*[[:blank:]]+([[:digit:]]+\/*[[:alnum:]]*),*[[:blank:]]+([[:digit:]]{5})'


I falsi positivi sono proprio pochi (la regola cerca di scartare tutti gli
indirizzi che non hanno numero civico e cap), soprattutto considerando il
marasma che c'è nei dati sorgente.

Concordo comunque sull'auspicio che i dati debbano essere standardizzati
alla fonte.

Ciao,

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

Re: [OSM-talk] GDPR introduction

[Christoph Hormann]

On Tuesday 17 April 2018, Simon Poole wrote:

>
> LWG GDPR Position Paper
> 
>
> Please feel free to discuss on the talk page
>  or on this list.

A number of questions/comments:

* Is there some sort of document outlining the data retention practice 
for user logins on the OSM website which according to your suggestion 
would be the basis of granting access to metadata in the future.  
Obviously some level of retention of such data is permitted (for abuse 
prevention etc.) but it would be nice to know how long and in what form 
such data is retained.  This is not directly related to the GDPR but 
would become increasingly relevant if functionality on the OSM website 
is more often subject to being logged in.

* I am not completely sure about the view of the LWG regarding the 
question if the geodata itself (that is geometries, tags and IDs of 
nodes, ways and relations) contains personal data according to the 
GDPR.  Your recommendations seem to indicate you think it does not but 
that is not necessarily self-evident.  Note i am not talking about 
special cases here where mappers add personal data (like names of 
people living in a house) although they should not, i am talking about 
normally mapped stuff where you could identify individual mappers from 
tagging and geometry characteristics and based on timing derived from 
feature IDs.

* When you add new 'terms of use' or 'data processing agreement' 
provisions that people who want to access OSM data with metadata need 
to agree to does that constitute an amendment of the ODbL and therefore 
a change in license?  If not would any downstream data user who 
distributes a derivative database be allowed to add similar terms of 
use that restrict use of the data to the data they distribute?

* Your position paper does not seem to mention the OAuth service - it 
seems to me registering an application to use this in the current form 
would also need to require a special agreement.  In addition it might 
be a good idea (i think i suggested this already in the past) to 
provide an anonymous OAuth service - where the application using it 
gets confirmation that the user is logged in as an registered OSM user 
but which does not provide any information on this user's identity.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] External contact channels and GDPR

[Simon Poole]

Isn't this a bit a "what if"?

Definitely the OSMF is not requiring or asking anybody to discuss topics
on media that are not operated by the foundation and as you know
provides a variety of options (changeset comments, diaries, mailing
lists and forums) that can be used without involving third parties. iD
now suggests options that are not OSMF operated, but that content is not
curated by the OSMF.

Further the intro to the privacy policy actually touches on the issue
https://wiki.osmfoundation.org/wiki/Privacy_Policy

Simon

Am 17.04.2018 um 07:51 schrieb Andrew Hain:
> The issue would be that we are asking someone to trust an external
> provider. At worst we could be responsible for propagating their
> noncompliance with the GDPR.
>
> --
> Andrewm
> 
> *From:* Kathleen Lu 
> *Sent:* 16 April 2018 23:11:11
> *To:* Andrew Hain
> *Cc:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] External contact channels and GDPR
>  
> Hi Andrew,
> It's not clear to me why GDPR would make it unacceptable in general to
> ask someone to discuss something, whether a controversial edit or not,
> in one forum or another, OSMF or not. What would be the concern?
> -Kathleen
>
>
> On Mon, Apr 16, 2018 at 9:18 PM Andrew Hain
> > wrote:
>
> When we ask mappers to discuss controversial edits or imports is
> it ever acceptable under GDPR to direct people to a contact
> channel that is not directly run by the OSMF?
>
> --
> Andrew
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



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

Re: [OSM-talk-fr] Un nouveau 'concurrent' ?

[Vincent Frison]

Le 16 avril 2018 à 11:39, Cédric Frayssinet  a écrit
:

>
> Merci Noémie pour ces précisions !
>
> Qwant étant un moteur de recherche, est-il prévu également d'améliorer le
> moteur actuel d'OpenStreetMap qui est pour moi le point faible autant sur
> OpenStreetMap.org que sur OsmAnd. En effet, une seule petite lettre en
> défaut et on n'obtient aucun résultat :( C'est une des grosses forces de
> GMaps pour le coup...
>
> Sur Mastodon, on m'a dit que ce serait chouette de se rapprocher de cette
> interface : https://en.mapy.cz/ et moi je rajoute celle-ci :
> https://maps.mapcat.com/
>

Je trouve Mapy.cz impressionnant, pour moi c'est peut-être la meilleure
webmap basée sur OSM ! Elle a quasiment tout, il manque juste la
possibilité de voir l'ensemble des données comme sur osm.org (par ex.
certains commerces ou restaurant ne sont pas visibles, même avec la carte
"touriste"). Bref merci pour le lien...

Pour revenir au sujet j'ai vraiment hâte de voir ce que Qwant va nous
proposer, c'est pas tous les jours qu'une "grosse" boite fait une solution
cartographique pour le grand public basée sur OSM...

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

Re: [Talk-cz] Ruske mapy

[Jan Macura]

Doporučuji zájemcům o sovětské mapové dílo:
https://maps.vlasenko.net/soviet-military-topographic-map/
Občas se tam najde i nějaký ten zahraniční kousek.

Jo a to, co odkazuje Majka je fakt už historie, vojáci mají dávno svoje
mapy v UTM, jsou součástí tajných materiálů NATO a jsou velmi
specializované k různým účelům.

H.

2018-04-17 10:49 GMT+02:00 majka :

>
>
> On Tue, 17 Apr 2018 at 10:38,  wrote:
>
>> U nas to bylo taky, jen v mensim meritku. Co hodin ja prolezel ve
>> vojenskych mapach Sumavy vydanych v roce 1991 pro verejnost... do te doby
>> byly turisticke v tom miste v jinem meritku a Rakousko/Nemecko byla zluta
>> plocha...
>>
>
> Pořád ještě existuje, jen mapy co vidím /vrstva vojenské rastrové/
>  nejsou aktualizované. Ale pořád
> ještě je tam spousta zajímavých údajů (výška porostu, u silnic počet pruhů,
> druh povrchu, dobře zmapované náspy a zářezy apod.). Pokud lezu někde "mimo
> cesty", pořád ještě předem nakouknu i do téhle mapy.
>
> ___
> 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-talk] GDPR introduction

[Simon Poole]

On the 25th of May 2018 the *General Data Protection Regulation (GDPR)
* will
enter in to force, this will likely result in some changes in how
OpenStreetMap operates and distributes its data.

The LWG has prepared a position paper on the matter that has been
reviewed by data protection experts and in general the approach to not
rely on explicit consent has been validated. It should be noted that
while the paper outlines our approach, some of the details still need to
be determined. In particular the future relationship with community and
third party data consumers that utilize OSM meta-data and what will
actually be dropped/made less accessible of the data listed in Appendix B.

LWG GDPR Position Paper


Please feel free to discuss on the talk page
 or on this list.

Simon



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

Re: [OSM-talk-fr] Exports OSM impossibles

[Sylvain M]

marc marc wrote
> mais l'utilisation du bouton export fonctionne chez moi

Étrange... !
Peux-tu me donner l'URL complète de l'exportation, qui fonctionne chez toi ?
Merci !

Sylvain M.




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

[Talk-cz] WeeklOSM CZ 401

[Tom Ka]

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

http://www.weeklyosm.eu/cz/archives/10179

* Vlastní renderer dlaždic.
* Označení městských částí.
* Maproulette 3.0.
* Routovací systémy a novinky v editoru iD.
* Repozitář 3D modelů.
* Kde bude SotM 2019?
* OpenStreetBrowser a gastronomické POI.
* Falešné cíle na dopravních značkách.
* Historické atlasy.
* Falcon 9 a nepřesnost GPS.

Pěkné počtení ...

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

Re: [Talk-it] Mappe mute

[Andreas Lattmann]

Può essere di qualche utilità questo?
https://github.com/Zverik/Nik4/blob/master/README.md so che esporta in SVG.
Scusa ma in questo momento non mi vengono in mente altri strumenti

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-dk] autoAWS første udkast

[Jonathan Hougaard]

Hej Jakob


Tak skal du have.

Lad os bare flytte diskussionen til wiki-siden, så undgår vi at sende en 
masse emails til folk der måske ikke er interesserede i projektet.


Mht. 4 - som nævnt tidligere, er min tilgang generelt (nødt til at 
være), at data fra DAR er korrekt. Jeg har ikke deltaget i den nævnte 
diskussion, og kender derfor ikke argumenterne. Teknisk kan jeg godt, 
hvis der er konsensus om det, rette forkortede vejnavne til deres fulde 
navn før de importeres. Dette kræver, at der er en eller anden, der 
laver en komplet liste med forkortelser og deres udvidede form (Dr. = 
Doktor, Nr. = Nørre osv.)


Umiddelbart har jeg lidt svært ved at forstå, hvorfor vi ønsker at ændre 
de tilsyneladende officielle vejnavne fra DAR, men som sagt kender jeg 
ikke argumenterne.


Mht. position, som tidligere diskuteret et sted i forrige tråd, bør fejl 
rettes direkte hos DAR. Hvis der er helt exceptionelle tilfælde hvor en 
adresseknude i OSM ikke skal placeres på den officielle placering (jeg 
kan ikke umiddelbart komme på nogen!), kan vi eventuelt anvende et 
specielt tag, så knuden bliver ignoreret (autoaws=ignore eller hvad ved 
jeg). Så vidt jeg forstår, har AWSbot haft en tilsvarende funktion.



On 17/04/2018 10:26, Jakob Barfod wrote:

I må meget gerne kigge beskrivelsen igennem og komme med forslag og
kommentarer til dette.

1. Rigtig godt arbejde!

2. Foretrækker du, at diskussion foregåer her på talk-dk eller på 
diskussionssiden på wiki'en?
2.a. Hvis her på talk-dk, så opretter jeg lige en henvisning på wiki'en.

3. Henvisninger til AWSbot på diverse wiki-sider bør opdateres, så AutoAWS 
nævnes i stedet. Ikke ment sådan, at _du_ skal gøre det, men hermed efterlyses 
steder, hvor vi bør opdatere diverse tekster. Fx...
3.a https://wiki.openstreetmap.org/wiki/Addresses#Denmark
3.b https://www.openstreetmap.org/user/AWSbot
3.c https://wiki.openstreetmap.org/wiki/Import/Catalogue/KMS
3.d Flere?

4. Konfliktende opdateringer? Hvem har ret, DAR eller OSM?
Jf. den gamle "Dr. Tværgade<>Doktor Tværgade"-diskussion, så lægger jeg mærke 
til, at stavningen fra DAR bruges, hvis der er forskel:

"Any one of the following conditions will trigger an update:
[...]
The position (lat and lon) of the node is not equal to the AWS address 
position
addr:street=* is not equal to the AWS street name "

Er det hensigtsmæssigt? Hvad nu hvis en OSM-bruger har tilrettet forkerte data 
(fx position eller stavning af vejnavn)? Det kan jeg simpelthen ikke gennemskue.




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

Re: [Talk-it] Mappe mute

[Maurizio Napolitano]

>[...] Maperitive mi pare sia solo disponibile
> per windows.

funziona anche su linux con mono

> Le mappe mute mi servono stampate...

maperitive esporta in pdf
Unica nota negativa: è  proprietario

> mia figlia ha il suo
> daffare per studiare i nomi di TUTTI i fiumi italiani. Ieri mi sono
> arrangiato con mappe cercate in google, ma spesso una bella vettoriale
> farebbe un figurone su formati >A4 oltrechè essere più pratica per scriverci
> le risposte :-)

Capisco.
Comunque potresti prenderti i fiumi da naturalearthdata (o da osm) e
poi usare mapstarter o mapshaper




> Il giorno 16 aprile 2018 23:27, liste DOT girarsi AT posteo DOT eu
>  ha scritto:
>>
>> Il 16/04/2018 14:52, Maurizio Napolitano ha scritto:
>>>
>>> 2018-04-15 21:13 GMT+02:00 Cascafico Giovanni :

 Ciao Listàti,

 prima di impelagarmi in qgis, sapete se ci sono in giro servizi per la
 generazione di mappe mute (blank maps)?

 per esempio, dei fiumi italiani, o campoluoghi ecc.
>>>
>>>
>>> Se intendi basate su OSM temo di no.
>>> L'unica cosa che mi viene da suggerire a pelle è provare a giocare con
>>> maperitive
>>>
>>
>> Non ho capito se ti serve per stampa, in tal caso, comunque c'è un
>> servizio di mappe da stampare, trovato dopo ricerca perchè mi ricordavo
>> qualcosa, e guarda a caso proprio proposto da Maurizio Napolitano tempo fa.
>>
>> Si chiama mapz.com, ho provato a giochicchiare, non è molto versatile,
>> almeno senza registrarsi (non si accede ai tab a lato), comunque, dopo aver
>> zoomato su una zona delle mie parti, cliccando a destra su "Multicolor Blind
>> Map", ottengo la mappa senza nomi.
>>
>> Se clicchi su altri pulsanti/stili, cambia qualcosa, comunque il servizio
>> è lento ad aggiornarsi, ci vuole un pò di pazienza.
>>
>> Per scaricare bisogna registrarsi.
>>
>>
>> [0] https://www.mapz.com/
>>
>>
>>
>>
>>
>>
>>
>> --
>> _|_|_|_|_|_|_|_|_|_
>> |_|_|_|_|_|_|_|_|_|_|
>> Simone Girardelli
>>
>>
>> ___
>> 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
>



-- 
Maurizio "Napo" Napolitano
http://de.straba.us

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

Re: [Talk-it] dataset MISE distributori

[Cascafico Giovanni]

Il giorno 28 marzo 2018 11:46, Andrea Musuruane  ha
scritto:

> Nel file description viene messo l'indirizzo. Sarebbe meglio riuscire a
>>> metterlo in addr:street e addr:housenumber (per quelli che hanno un numero
>>> civico, per gli altri l'informazione mi sembra inutile).
>>>
>>
>> Onestamente non saprei come processare la stringa... l'unica certezza di
>> questo campo è il codice postale alla fine. La ho assegnata a description,
>> pensando che il mappatore occasionale possa eventualemnte aggiungere il
>> civico manualmente. Anche il no rari riferimenti kilometrici (p.es. "Ss
>> 356 Km 45+5112") potrebbero essere utili per mettere qualche milestone,
>> seppure mi pare siano relegate ad ogetti historic.
>>
>
> Si può fare in questo modo.
>
> Estrai tre valori dalla stringa in base alla seguente espressione regolare:
> (.*),*\s+(\d+\/*\w*),*\s+(\d{5})
>
> Se l'espressione regolare non è soddisfatta si scarta la stringa.
>

Ho applicato al regexp in qgis (necessario anteporre un ulteriore backslash
ad ogni backslash)
regexp_substr ("Indirizzo", '(.*),*\\s+(\\d+\\/*\w*),*\s+(\\d{5})' )

ed estrae il nome strada per circa metà dei record. Speriamo che il modulo
online che il MISE sta pubblicando per i gestori ci semplichi la vita :-)


>
A questo punto, compili i campi addr:street con il primo valore,
> addr:housenumber con il secondo (rimuovendo lo slash se questa è seguito
> solo da lettere), addr:postcode con il terzo e addr:city con il valore del
> campo COMUNE.
>
> Da notare che bisognerà comunque fare qualche passo di QA perché il valore
> del campo addr:street difficilmente sarà uguale a quello della strada
> inserita in OSM, siccome i dati sorgente non rispettano le regole OSM
> (niente abbreviazioni, ecc).
>

per gli odonimi persone, direi che non vengono mai rispettate.



> Mi chiedo però se ha senso importare gli indirizzi nelle aree dove è già
> stato fatto un import (o dove sarà fatto).
>

Il tool di conflation prevede di non sovrascrivere i tag già valorizzati: è
necessario definirli esplicitamente.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Ruske mapy

[majka]

On Tue, 17 Apr 2018 at 10:38,  wrote:

> U nas to bylo taky, jen v mensim meritku. Co hodin ja prolezel ve
> vojenskych mapach Sumavy vydanych v roce 1991 pro verejnost... do te doby
> byly turisticke v tom miste v jinem meritku a Rakousko/Nemecko byla zluta
> plocha...
>

Pořád ještě existuje, jen mapy co vidím /vrstva vojenské rastrové/
 nejsou aktualizované. Ale pořád
ještě je tam spousta zajímavých údajů (výška porostu, u silnic počet pruhů,
druh povrchu, dobře zmapované náspy a zářezy apod.). Pokud lezu někde "mimo
cesty", pořád ještě předem nakouknu i do téhle mapy.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Ruske mapy

[jozka]

Obavam se, ze by mel asi tak tricet let zpozdeni...

U nas to bylo taky, jen v mensim meritku. Co hodin ja prolezel ve vojenskych 
mapach Sumavy vydanych v roce 1991 pro verejnost... do te doby byly turisticke 
v tom miste v jinem meritku a Rakousko/Nemecko byla zluta plocha...

Ale pamatuji si jeste z brane vychovy vojenske mapy co mely informace typu 
vyska/rozestup stromu...

J.

__
> Od: Pavel Machek 
> Komu: talk-cz@openstreetmap.org
> Datum: 17.04.2018 10:07
> Předmět: [Talk-cz] Ruske mapy
>
>
>Nechysta se nekdo do Ruska koupit tam nejake bedny s mapama? :-)
>
>https://xman.idnes.cz/sovetske-tajne-vojenske-mapy-dj5-/xman-styl.aspx?c=A180416_145157_xman-styl_fro
>
>Nenapadlo me jak moc jsou mapy dulezite pro vojaky.
>   Pavel
>-- 
>(english) http://www.livejournal.com/~pavelmachek
>(cesky, pictures) 
>http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
>
>--
>
>___
>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-dk] autoAWS første udkast

[Jakob Barfod]

> I må meget gerne kigge beskrivelsen igennem og komme med forslag og
> kommentarer til dette.

1. Rigtig godt arbejde!

2. Foretrækker du, at diskussion foregåer her på talk-dk eller på 
diskussionssiden på wiki'en?
2.a. Hvis her på talk-dk, så opretter jeg lige en henvisning på wiki'en.

3. Henvisninger til AWSbot på diverse wiki-sider bør opdateres, så AutoAWS 
nævnes i stedet. Ikke ment sådan, at _du_ skal gøre det, men hermed efterlyses 
steder, hvor vi bør opdatere diverse tekster. Fx...
3.a https://wiki.openstreetmap.org/wiki/Addresses#Denmark
3.b https://www.openstreetmap.org/user/AWSbot
3.c https://wiki.openstreetmap.org/wiki/Import/Catalogue/KMS 
3.d Flere?

4. Konfliktende opdateringer? Hvem har ret, DAR eller OSM?
Jf. den gamle "Dr. Tværgade<>Doktor Tværgade"-diskussion, så lægger jeg mærke 
til, at stavningen fra DAR bruges, hvis der er forskel:

   "Any one of the following conditions will trigger an update: 
   [...]
   The position (lat and lon) of the node is not equal to the AWS address 
position 
   addr:street=* is not equal to the AWS street name "

Er det hensigtsmæssigt? Hvad nu hvis en OSM-bruger har tilrettet forkerte data 
(fx position eller stavning af vejnavn)? Det kan jeg simpelthen ikke gennemskue.

-- 
Jakob


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

Re: [Talk-it] Mappe mute

[Cascafico Giovanni]

Grazie, sto provando mapz adesso. Maperitive mi pare sia solo disponibile
per windows. Le mappe mute mi servono stampate... mia figlia ha il suo
daffare per studiare i nomi di TUTTI i fiumi italiani. Ieri mi sono
arrangiato con mappe cercate in google, ma spesso una bella vettoriale
farebbe un figurone su formati >A4 oltrechè essere più pratica per
scriverci le risposte :-)

Il giorno 16 aprile 2018 23:27, liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu> ha scritto:

> Il 16/04/2018 14:52, Maurizio Napolitano ha scritto:
>
>> 2018-04-15 21:13 GMT+02:00 Cascafico Giovanni :
>>
>>> Ciao Listàti,
>>>
>>> prima di impelagarmi in qgis, sapete se ci sono in giro servizi per la
>>> generazione di mappe mute (blank maps)?
>>>
>>> per esempio, dei fiumi italiani, o campoluoghi ecc.
>>>
>>
>> Se intendi basate su OSM temo di no.
>> L'unica cosa che mi viene da suggerire a pelle è provare a giocare con
>> maperitive
>>
>>
> Non ho capito se ti serve per stampa, in tal caso, comunque c'è un
> servizio di mappe da stampare, trovato dopo ricerca perchè mi ricordavo
> qualcosa, e guarda a caso proprio proposto da Maurizio Napolitano tempo fa.
>
> Si chiama mapz.com, ho provato a giochicchiare, non è molto versatile,
> almeno senza registrarsi (non si accede ai tab a lato), comunque, dopo aver
> zoomato su una zona delle mie parti, cliccando a destra su "Multicolor
> Blind Map", ottengo la mappa senza nomi.
>
> Se clicchi su altri pulsanti/stili, cambia qualcosa, comunque il servizio
> è lento ad aggiornarsi, ci vuole un pò di pazienza.
>
> Per scaricare bisogna registrarsi.
>
>
> [0] https://www.mapz.com/
>
>
>
>
>
>
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 105, Udgave 7

[Jørgen Elgaard Larsen]

Anders Lund skrev:

Alle de pokkers små flækker ødelægger stedsøgningen (reverse geosearch fx på
osm.org) fra et bruger-synspunkt. Søgning efter adresser i danmark giver ret
absurde resulater, fordi flækkerne er punkter, og der ingen regler er for
hornår de er relevante.


Jeg vil mene, at de absurde resultater primært skyldes, at 
adressesøgningerne (begge veje) som regel ignorerer Karlsruhe-skemaet og 
udelukkende baserer sig på is-in.


Det er især et problem i Danmark, hvor vi følger Karlsruhe, men ikke har 
postnummer-områder i vores kort. De fleste adresse-søgestjenester går i 
panik, når en adresse ikke ligger i et postnummer-område. Så vælger de 
et place i nærheden.


Vi har tidligere talt om at lægge danske postnummer-områder ind i kortet 
- det ville hjælpe en del på adressesøgning.


- Jørgen

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

Re: [OSM-talk-fr] Banque, brand et brand:wikidata

[Julien Noblet]

Le 17/04/2018 à 09:59, marc marc a écrit :

Le 17. 04. 18 à 09:25, Julien Noblet a écrit :

J'utilise brand et non opérator car même si c'est souvent identique dans
le cas des banques (il y a peu d'indépendants dans le domaine),

On serrait surpris :)
généralement le seul moyen pour un client de savoir si une agence est
salarié ou franchisé, c'est de regarder sur les documents qu'on signe
dans cette agence. en cas de franchise, tu as les coordonnées de la
franchise et le fait qu'elle agit pour le nom du groupe.
Pour cette raison je pense que la majorité des agences bancaires dans
osm ont un tag operator supposé (donc autant pas mettre plutôt que de
faire de la devinette). idem pour les fastfood par exemple.
D'autant qu'avoir un operator sur un fastfood a un intérêt limité a mon 
avis.
brand est plus pertinent, lorsque je cherche un m*c do. Je me fiche de 
savoir qui est le gérant  ^^



Par exemple la Relation 287171
, nous avons:
# name=Crédit Mutuel de Bretagne
# operator=Crédit Mutuel

A mon avis cela devrais être:
# name=Crédit Mutuel de Bretagne Chantepie
# brand=Crédit Mutuel
# operator=Crédit Mutuel de Bretagne

brand=Crédit Mutuel
operator : je n'y toucherais pas sauf si tu as une source valide.
name="Caisse de crédit mutuel Chantepie" (c'est moche mais c'est le nom
que le CM utilise
https://www.creditmutuel.fr/banques/contact/trouver-une-caisse/SearchList.aspx?type=branch===Chantepie=29=11=true=False===

Ici je pencherai pour remplacer le operator par le brand.


une recherche par name ne sort pas toutes les occurences,

exact, sans compter que dans certain réseau, le nom correct est parfois
du style "agence de tel-lieu" sans que la marque n'apparaisse dans le nom.
Le seul tag pertinent pour ce genre de recherche est à mon avis brand,
d’où l’intérêt de l'ajouter.

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


Du coup, je pensait faire une requette assez généraliste comme celle ci :
http://overpass-turbo.eu/s/xXL



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

Re: [OSM-talk-fr] Banque, brand et brand:wikidata

[PanierAvide]

+1 pour la démarche sur les banques :-)

Pour le nom c'est effectivement long et/ou pas adéquat (pas forcément 
moche, vu que c'est le nom du lieu). Ce qui est moche, c'est que le 
rendu international ne gère toujours pas le brand=*. Sur un 
établissement qui en dispose, il devrait être utilisé (et éviter l'usage 
en doublon du name=* pour remettre la même chose que le brand sans 
préciser le nom précis de l'établissement). Comme on ne tague pas pour 
le rendu, je vous encourage vivement à mettre le nom précis dans name=*, 
le rendu s'adaptera (un jour (j'espère)).


Adrien.


Le 17/04/2018 à 09:59, marc marc a écrit :

Le 17. 04. 18 à 09:25, Julien Noblet a écrit :

J'utilise brand et non opérator car même si c'est souvent identique dans
le cas des banques (il y a peu d'indépendants dans le domaine),

On serrait surpris :)
généralement le seul moyen pour un client de savoir si une agence est
salarié ou franchisé, c'est de regarder sur les documents qu'on signe
dans cette agence. en cas de franchise, tu as les coordonnées de la
franchise et le fait qu'elle agit pour le nom du groupe.
Pour cette raison je pense que la majorité des agences bancaires dans
osm ont un tag operator supposé (donc autant pas mettre plutôt que de
faire de la devinette). idem pour les fastfood par exemple.


Par exemple la Relation 287171
, nous avons:
# name=Crédit Mutuel de Bretagne
# operator=Crédit Mutuel

A mon avis cela devrais être:
# name=Crédit Mutuel de Bretagne Chantepie
# brand=Crédit Mutuel
# operator=Crédit Mutuel de Bretagne

brand=Crédit Mutuel
operator : je n'y toucherais pas sauf si tu as une source valide.
name="Caisse de crédit mutuel Chantepie" (c'est moche mais c'est le nom
que le CM utilise
https://www.creditmutuel.fr/banques/contact/trouver-une-caisse/SearchList.aspx?type=branch===Chantepie=29=11=true=False===


une recherche par name ne sort pas toutes les occurences,

exact, sans compter que dans certain réseau, le nom correct est parfois
du style "agence de tel-lieu" sans que la marque n'apparaisse dans le nom.
Le seul tag pertinent pour ce genre de recherche est à mon avis brand,
d’où l’intérêt de l'ajouter.

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-cz] Ruske mapy

[Pavel Machek]

Nechysta se nekdo do Ruska koupit tam nejake bedny s mapama? :-)

https://xman.idnes.cz/sovetske-tajne-vojenske-mapy-dj5-/xman-styl.aspx?c=A180416_145157_xman-styl_fro

Nenapadlo me jak moc jsou mapy dulezite pro vojaky.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Banque, brand et brand:wikidata

[marc marc]

Le 17. 04. 18 à 09:25, Julien Noblet a écrit :
> J'utilise brand et non opérator car même si c'est souvent identique dans 
> le cas des banques (il y a peu d'indépendants dans le domaine),

On serrait surpris :)
généralement le seul moyen pour un client de savoir si une agence est 
salarié ou franchisé, c'est de regarder sur les documents qu'on signe 
dans cette agence. en cas de franchise, tu as les coordonnées de la 
franchise et le fait qu'elle agit pour le nom du groupe.
Pour cette raison je pense que la majorité des agences bancaires dans 
osm ont un tag operator supposé (donc autant pas mettre plutôt que de 
faire de la devinette). idem pour les fastfood par exemple.

> Par exemple la Relation 287171 
> , nous avons:
> # name=Crédit Mutuel de Bretagne
> # operator=Crédit Mutuel
> 
> A mon avis cela devrais être:
> # name=Crédit Mutuel de Bretagne Chantepie
> # brand=Crédit Mutuel
> # operator=Crédit Mutuel de Bretagne

brand=Crédit Mutuel
operator : je n'y toucherais pas sauf si tu as une source valide.
name="Caisse de crédit mutuel Chantepie" (c'est moche mais c'est le nom 
que le CM utilise
https://www.creditmutuel.fr/banques/contact/trouver-une-caisse/SearchList.aspx?type=branch===Chantepie=29=11=true=False===

> une recherche par name ne sort pas toutes les occurences,

exact, sans compter que dans certain réseau, le nom correct est parfois 
du style "agence de tel-lieu" sans que la marque n'apparaisse dans le nom.
Le seul tag pertinent pour ce genre de recherche est à mon avis brand,
d’où l’intérêt de l'ajouter.

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

[Talk-dk] autoAWS første udkast

[Jonathan Hougaard]

Hej alle


Tak for de mange input og kommentarer på min tidligere email om et nyt 
script til opdatering af adressedata i Danmark.


Jeg har opdateret wiki-siden, så den gerne skulle stemme overens med 
koden som den ser ud lige nu: https://wiki.openstreetmap.org/wiki/AutoAWS


I må meget gerne kigge beskrivelsen igennem og komme med forslag og 
kommentarer til dette.


Da enkelte af jer har været meget ivrige efter at få fingre i 
kildekoden, selvom den på ingen måde er færdig, har jeg uploadet den 
foreløbige kode her: https://pastebin.com/qtwkiUVa


Bemærk venligst, at de enkelte del-funktioner er nået et godt stykke 
vej, men jeg mangler stadig at samle det hele i main(). Desuden mangler 
jeg at indføre en hel del fejlhåndtering. Et par steder har jeg indført 
en die() for at undgå at arbejde med/indføre korrupt data, disse vil 
selvfølgelig blive erstattet af en lidt mere fornuftig fejlhåndtering.


Delelementer af koden er testet mod OSM's developer API. For eksempel 
vil i bemærke, at der nu findes næsten 1000 adresse-noder i Aalborg i 
denne ... (se 
https://master.apis.dev.openstreetmap.org/user/autoAWS/history)


Kommentarer på selve koden modtages også gerne, men som sagt er den 
stadig noget "grov i kanterne" da jeg egentlig ikke havde planer om at 
offentliggøre den i et så tidligt stadie.



Venligst

Jonathan


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

Re: [OSM-talk-fr] Banque, brand et brand:wikidata

[Julien Noblet]

Le 17/04/2018 à 09:39, Dominique Rousseau a écrit :

Le Tue, Apr 17, 2018 at 07:25:08AM +, Julien Noblet 
[julien.nob...@gmail.com] a écrit:
[...]

De plus, si je prends l'example du Crédit Mutuel ou de la Banque Populaire,
il me semble que l'on a des société régionnales qui sont sous une seule et
même banière.

C'est la même chose pour la Caisse d'Épargne, pour le Crédit Agricole,
le CIC.
(en fait toutes les banques "mutualistes" :)
Du coup on devrais pas voir ici http://overpass-turbo.eu/s/xXJ ces 460 
operator=CIC :)







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

Re: [OSM-talk-fr] Banque, brand et brand:wikidata

[Dominique Rousseau]

Le Tue, Apr 17, 2018 at 07:25:08AM +, Julien Noblet 
[julien.nob...@gmail.com] a écrit:
[...]
> De plus, si je prends l'example du Crédit Mutuel ou de la Banque Populaire,
> il me semble que l'on a des société régionnales qui sont sous une seule et
> même banière.

C'est la même chose pour la Caisse d'Épargne, pour le Crédit Agricole,
le CIC.
(en fait toutes les banques "mutualistes" :)


-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

[OSM-talk-fr] Banque, brand et brand:wikidata

[Julien Noblet]

Bonjour,

Je viens de lire le fil d'Adrien sur wikidata vs brand:wikidata et
j'aimerai de reprendre le principe pour certaines banques.
Je propose donc de rajouter le brand et brand:wikidata sur ces dernières
pour simplifier les recherches.

J'utilise brand et non opérator car même si c'est souvent identique dans le
cas des banques (il y a peu d'indépendants dans le domaine), je ne suis pas
sur qu'une entité soit bien une filliale du groupe.
De plus, si je prends l'example du Crédit Mutuel ou de la Banque Populaire,
il me semble que l'on a des société régionnales qui sont sous une seule et
même banière.
Par exemple la Relation 287171
, nous avons:
...
- name=Crédit Mutuel de Bretagne
- operator=Crédit Mutuel...

A mon avis cela devrais être:
...
- name=Crédit Mutuel de Bretagne Chantepie
- brand=Crédit Mutuel
- operator=Crédit Mutuel de Bretagne
- ...

Les spécialistes me corrigerons, je n'en doute pas.
Pour le moment, ne connaissant pas bien le liens de filliations donc je me
concentre uniquement sur le tag "brand" (jumelé avec brand:wikidata)
J'ai commencé sur avec LCL en faisant des recherches croisées.
Je vais essayer de créer un maproulette pour ajouter ces dernières et ne
pas être seul à faire cela :).


Pour l'histoire, je cherchait ou était la banque la plus proche mais
également la densité des banques du même réseau.
Je me suis rendu compte que c'etait pas aussi simple, une recherche par
name ne sort pas toutes les occurences,
Il y a aussi certaines baques sans nom mais avec un operator ou brand
uniquement...
Certaines on un nom du style name=Banque tartampion du centre-ville ce qui
complique pas mal les recherches...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr