Re: [Talk-br] HOTOSM Tasking Manager - Barragem em Brumadinho

[Theo A]

O projeto provavelmente será feito em breve, então, se pudermos obter a
documentação sobre a licença, poderemos usá-lo para revisar depois.

On Sun, 27 Jan 2019 at 18:45, Alexandre Oliveira 
wrote:

> Para armazenar as imagens, seria necessário somente um servidor, ou
> teria que fazer alguma outra coisa com elas?
>
> On 27/01/2019 08:51, Theo A wrote:
> > Obrigada, estamos trabalhando nisso. Sabem se essa informação está
> > armazenada em algum lugar? Se não conseguirmos armazená-la,  o público
> não
> > terá condições de adicionar imagens manualmente
> >
> > On Sat, 26 Jan 2019 at 23:29, Narcélio de Sá Pereira Filho <
> > narceliosapere...@gmail.com> wrote:
> >
> >> Prezado segue o link para download de uma Imagem PLEIADES de 50 cm de
> >> resolução colorida RGB de 18-01-19 de Brumadinho. MG, Mina Corrego do
> >> Feijão. Ortoretificada UTM WGS 84 Fuso 23 S GEOTIF , KMZ e ECW.
> >> Ortoretificada com parâmetros orbitais. A mesma pode ser utilizada para
> o
> >> pŕe-mapeamento da área do sinistro.
> >> link:
> >> http://www.engesat.com.br/sobre-brumadinho-mg-dia-25-01-19/
> >>
> >> Atenciosamente
> >> *[image: cropped-logo_512.png]*
> >>
> >> *Narcélio de Sá*
> >> Mestre em Geografia - UFC
> >> Analista de Sistema de Informação Geográfica - CAGECE
> >> Coordenador da comunidade QGIS Brasil 
> >> www.narceliodesa.com
> >> [image: Facebook] 
> [image:
> >> Twitter]  [image: Google Plus]
> >> <
> https://plus.google.com/+Narc%C3%A9liodeS%C3%A1pereirafilho/posts?hl=pt_br
> >
> >>  [image: Youtube] 
> [image:
> >> Linkedin] 
> >>
> >>
> >> Em sáb, 26 de jan de 2019 às 18:03, Theo A 
> >> escreveu:
> >>
> >>> Caros membros da OSM Brazil,
> >>>
> >>>
> >>>
> >>> O Humanitarian OpenStreetMap Team está consciente dos acontecimentos
> nas
> >>> áreas ao redor da barragem em Brumadinho.
> >>>
> >>>
> >>>
> >>> Estamos em processo de criação de novas tasks no nosso Tasking Manager
> >>> para ajudar nos esforços de recuperação. Nosso Tasking Manager, que
> poderá
> >>> ser encontrado encontrado através do link https://tasks.hotosm.org/
> >>> <
> https://slack-redir.net/link?url=https%3A%2F%2Ftasks.hotosm.org%2F=3>,
> >>> dirige os usuários para areas específicas que serão mapeadas no
> >>> OpenStreetMaps, ajudando assim a coordenar os esforços de recuperação.
> >>>
> >>>
> >>>
> >>> Caso haja qualquer pergunta, por favor sintam-se à vontade para nos
> >>> contactar: activat...@hotosm.org ou faça parte da conversa no nosso
> >>> Slack: http://slack.hotosm.org/
> >>>  >
> >>> .
> >>>
> >>>
> >>>
> >>> Obrigado com antecedência por suas contribuições.
> >>>
> >>>
> >>>
> >>> Cumprimentos,
> >>>
> >>> Humanitarian OpenStreetMap Team - Disaster Activation Coordination.
> >>> ___
> >>> Talk-br mailing list
> >>> Talk-br@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-br
> >>>
> >> ___
> >> Talk-br mailing list
> >> Talk-br@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-br
> >>
> >
> >
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-br
> >
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk] Looking for phot of mapping mappers

[Rodrigo Rodríguez]

On 22/1/19 14:57, Mateusz Konieczny wrote:
> I am looking for a good photo of mappers mapping during survey. It turns
> to be surprisingly hard.
> 
> Can someone share/link one?

You can find some photos from the Mapanica team activities here:
https://www.flickr.com/photos/xamanu/albums/ and here:
https://www.flickr.com/photos/roirobo/sets/7215764175225

> 
> - I am not interested in photos of groups of mappers before mapping or
> after mapping
> - I am not looking for image of people sitting in front of computers and
> ebntering data
> - I am looking for good photograph that is not blurry/low
> resolution/overexposed
> - I prefer to avoid highly noticeable ads in background or on clothes of
> mappers
> - It would be great to show faces of people that can be recognised as
> mapping something
> 
> I tried searching via standard googling, and also looking at more
> specialized searches.
> I failed to find anything useful at OSM wiki – even
> https://wiki.openstreetmap.org/wiki/Mapping_parties
> had no picture of mapping until today (I just added one)!
> 
> Wikimedia Commons
> https://commons.wikimedia.org/wiki/Category:OpenStreetMap_mapping_parties 
> turned
> out to be quite useful.
> 
> I found http://farm3.static.flickr.com/2750/4497593337_48502971da.jpg at
> https://www.hotosm.org/updates/2010-04-08_mission_1_recap_of_the_second_week_conducting_training_and_outreach_on_openstree
> 
> Unfortunately it is low resolution and (presumably) fully copyrighted,
> also crop is a bit ankward.
> 
> https://commons.wikimedia.org/wiki/File:Wikimania_2013_HK_ZvD_11.JPG is
> unfortunately not showing faces
> 
> https://commons.wikimedia.org/wiki/File:Wikimania_2013_HK_ZvD_09.JPG -
> shop is more visible than people
> 
> https://commons.wikimedia.org/wiki/File:OSM_Mapathon_in_Albania_09.jpg -
> really like emotions here, unfortunately background is badly overexposed
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
Est-ce un polygone irrégulier ou un effet de perspective? Comment le 
représenter?
"59879471"    "22"    "FB_irreg"    
"{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"    
"{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"

Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
"657790097"    "5"    "FB_irreg"    "{o,o,ir,o,o}"    "{90,91,177.6,91.4,90}" 
Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un premier 
contributeur le voit et dit cela ne semble pas normal et y ajoute un peu de 
distorsion. Un deuxième décide d'y ajouter un point et d'étirer le tout. Si on 
poursuit le dessin dans ce sens, cela finira par ressembler à un clown!


Pierre 
 

Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan 
 a écrit :  
 
 If you take a look at 942 Bridle Path Crescent for example whilst it isn't 
exactly square the deviations from 90 degrees to me are relatively minor.  I 
assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
Are we expecting too high a standard?
Cheerio John

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

Re: [talk-ph] Request for clarification on road tagging guidelines

[Erwin Olario]

The segment in question should be `primary_link`, following the attributes
of the higher highway.

On Mon, Jan 28, 2019 at 11:44 AM grab osm  wrote:

> Apologize Erwin.
>
> Here are the further details of our question.
>
> When a way segment that connects to a Major road, please suggest if the
> the connector should have same classification as the way segment or that of
> a Major Road with link attribute assigned
>
> Below is an example:
> [image: image]
> 
> Please suggest, if any further infirnation is needed.
>
> Thanks
> Lavanya
>
>
> On Mon, Jan 28, 2019, 08:58 Erwin Olario 
>>
>> I think it's bad form to just post a ticket link here, without actually
>> specifying your question.
>>
>> If you post something here, expect answers to be answered here as well.
>> Your ticket tracking system is your own, not the community's.
>>
>>
>>
>>
>> On Mon, Jan 28, 2019 at 10:23 AM grab osm via talk-ph <
>> talk-ph@openstreetmap.org> wrote:
>>
>>> Good Morning Everyone,
>>>
>>> Request a quick clarification on road tagging guidelines.
>>> We have created an issue in our github page and here is the link.
>>> https://github.com/GRABOSM/Grab-Data/issues/30
>>> Kindly take time to review and suggest
>>>
>>> Thanks
>>> Lavanya
>>> ___
>>> talk-ph mailing list
>>> talk-ph@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ph
>>>
>> --
>>
>> /Erwin Olario
>>
>> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
>> https://mstdn.io/@GOwin
>>
> --

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-ph] Request for clarification on road tagging guidelines

[grab osm via talk-ph]

Apologize Erwin.

Here are the further details of our question.

When a way segment that connects to a Major road, please suggest if the the
connector should have same classification as the way segment or that of a
Major Road with link attribute assigned

Below is an example:
[image: image]

Please suggest, if any further infirnation is needed.

Thanks
Lavanya

On Mon, Jan 28, 2019, 08:58 Erwin Olario 
> I think it's bad form to just post a ticket link here, without actually
> specifying your question.
>
> If you post something here, expect answers to be answered here as well.
> Your ticket tracking system is your own, not the community's.
>
>
>
>
> On Mon, Jan 28, 2019 at 10:23 AM grab osm via talk-ph <
> talk-ph@openstreetmap.org> wrote:
>
>> Good Morning Everyone,
>>
>> Request a quick clarification on road tagging guidelines.
>> We have created an issue in our github page and here is the link.
>> https://github.com/GRABOSM/Grab-Data/issues/30
>> Kindly take time to review and suggest
>>
>> Thanks
>> Lavanya
>> ___
>> talk-ph mailing list
>> talk-ph@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ph
>>
> --
>
> /Erwin Olario
>
> e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s:
> https://mstdn.io/@GOwin
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [talk-ph] Request for clarification on road tagging guidelines

[Erwin Olario]

I think it's bad form to just post a ticket link here, without actually
specifying your question.

If you post something here, expect answers to be answered here as well.
Your ticket tracking system is your own, not the community's.




On Mon, Jan 28, 2019 at 10:23 AM grab osm via talk-ph <
talk-ph@openstreetmap.org> wrote:

> Good Morning Everyone,
>
> Request a quick clarification on road tagging guidelines.
> We have created an issue in our github page and here is the link.
> https://github.com/GRABOSM/Grab-Data/issues/30
> Kindly take time to review and suggest
>
> Thanks
> Lavanya
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[talk-ph] Request for clarification on road tagging guidelines

[grab osm via talk-ph]

Good Morning Everyone,

Request a quick clarification on road tagging guidelines.
We have created an issue in our github page and here is the link.
https://github.com/GRABOSM/Grab-Data/issues/30
Kindly take time to review and suggest

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

Re: [OSM-talk] junction=yes

[Jack Armstrong dan...@sprynet.com]

Thank you for the good information, Johnparis. Apparently, the wiki for junction=yes has now been modified for clarity.-Original Message-
From: Johnparis 
Sent: Jan 27, 2019 2:48 AM
To: Talk 
Subject: Re: [OSM-talk] junction=yes

It's pretty clear that the intention of this tag is only for junctions that have a name. It was part of this proposal:https://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_namesI think it would be appropriate to add some background to the wiki, and in particular to clarify the "When not to use" section.https://wiki.openstreetmap.org/wiki/Tag:junction%3DyesOn Sat, Jan 26, 2019 at 11:27 PM Jack Armstrong dan...@sprynet.com  wrote:Some users are adding junction=yes to every intersection, large or small. This seems very much incorrect to me. Is there a definitive answer as to whether this is correct or not?https://www.openstreetmap.org/edit#map=19/-0.17531/-78.48083

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

www.theaveragenomad.com

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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

Hi Colin,

Dependent and doubly dependent localities are technical terms and without 
having access to PAF most mappers wouldn't know which one to use. And if they 
did, that could be considered a copyright infringement. Also, it just doesn't 
sound right. No one asks "which dependent locality do you live in". I agree it 
matches PAF very well, though.

I agree towns and villages are less precise but since we already have them as 
admin levels that would be the easiest and most intuitive solution. We already 
have addr:suburb and addr:hamlet so that would be a natural extension, and one 
which is already in use in the UK. 

I agree with you on addr:parentstreet. The issue here is that house numbers and 
names are associated with either addr:street or addr:place. So if we were to 
introduce addr:substreet or addr:campus that convention would have to be 
changed. For this reason I suggested using addr:place as a dependent 
thoroughfare.This would only require allowing both street and place to be 
defined together.

Best regards,
Andrzej 

On 28 January 2019 07:05:40 GMT+08:00, Colin Smale  
wrote:
>Hi Andrezej,
>
>I would oppose addr:village for the Dependent Locality as it invites
>incorrect usage. There is no reason to overload an existing tag with a
>different meaning to its current usage. In the UK, a village is not
>simply a neat subdivision of a town. I think addr:locality and
>addr:sublocality would be better, as this would (correctly) imply a
>possibly fuzzy boundary which possibly crosses formal admin boundaries.
>
>
>Regarding streets/thoroughfares, the main thoroughfare is addr:street -
>that is clear and established usage. We are looking for a solution for
>a
>"substreet" and moving the main thoroughfare up to "addr:parentstreet"
>to make room for the dependent thoroughfare in "addr:street" feels
>wrong
>as it gives addr:street different semantics under some conditions. Note
>also that the word "thoroughfare" has probably been carefully chosen to
>allow application to things other than simple streets with adresses
>neatly on each side. I would also instinctively expect a campus to be
>more of a locality (subarea of a Town) than a super-street. Maybe
>someone with access to PAF data can see what data is in what fields for
>some address on the CSP. 
>
>It wouldn't surprise me if subbuildings were used for "Unit 1",
>"Building A" etc. That doesn't sound/feel at all unreasonable. 
>
>On 2019-01-27 23:27, Andrzej wrote:
>
>> Hi Colin,
>> 
>> This is broadly in line with Robert's proposals. However, it raises
>questions about:
>> 
>> 1. tagging "dependent localities" - they can be towns or villages.
>Are you happy with addr:town, addr:village for this purpose? Reaching
>consensus on that would be a major step forward. 
>> 
>> 2. Tagging "dependent throughfares". I think they could be used to
>tag "building name, Cambridge Science Park, Milton Road, Cambridge".
>This could be addr:place except in OSM addr:place should not be
>combined with addr:street. Or, like in Robert's proposal,
>addr:street+addr:parentstreet. Except that CSP is a campus, not a
>street. 
>> 
>> 3. Tagging subbuildings. Addr:unit is available but is fairly limited
>(unit names?) and vague. 
>> 
>> 4. PO Box - I haven't thought about it. Is that something that we
>would include at all in a geographical database? Perhaps if it is
>associated with a business that has a known location but uses PO Box as
>its address? 
>> 
>> Best wishes,
>> Andrzej 
>> 
>> On 28 January 2019 05:21:36 GMT+08:00, Colin Smale
> wrote: 
>> 
>> Assuming the post code is seen in OSM as a way of addressing post (as
>opposed to a geographic subdivision or an indication of location) then
>I suggest following Royal Mail's address structure, which can be seen
>in the description of the Postcode Address File on Wikipedia [1]. If we
>cannot map a full-format address onto OSM tags, we need a description
>of how to deal with this (i.e. which bits to leave out or combine). 
>> 
>> I have taken the table from wikipedia and added a column for the OSM
>tags where known. Most of these fields are actually optional, or not
>always present, depending on the exact address in question. 
>> 
>> How do we fill in the blanks? 
>> 
>> ELEMENT
>> FIELD NAME
>> DESCRIPTION
>> MAX LENGTH
>> OSM
>> 
>> Organisation
>> Organisation Name
>> 
>> 60
>> n/a
>> 
>> Department Name
>> 
>> 60
>> n/a
>> 
>> Premises
>> Sub Building Name
>> 
>> 30
>> 
>> Building Name
>> 
>> 50
>> addr:housename
>> 
>> Building Number
>> 
>> 4
>> addr:housenumber
>> 
>> Thoroughfare
>> Dependent Thoroughfare Name
>> 
>> 60
>> 
>> Dependent Thoroughfare Descriptor
>> 
>> 20
>> 
>> Thoroughfare Name
>> Street
>> 60
>> addr:street
>> 
>> Thoroughfare Descriptor
>> 
>> 20
>> 
>> Locality
>> Double Dependent Locality
>> Small villages
>> 35
>> 
>> Dependent Locality
>> 
>> 35
>> 
>> Post town
>> 
>> 30
>> addr:city
>> 
>> Postcode
>> Postcode
>> 
>> 7
>> addr:postcode
>> 
>> PO Box
>> PO Box
>> 
>> 6
>> 
>> [1] 

Re: [Talk-de] Overpass Abfrage

[Martin Scholtes]

Hab da noch eine Frage: Versuche eine Relation über (area:XYZ) mit dem
36 Vorwahl zu ergreifen. Leider funktioniert das i-wie nicht. Es
geht um die ID 4168993.

Gruß
Martin

Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> Hallo Martin,
>
> du bekommst dem Mittelpunkt bei POIs mit "out center" und die Ausgabe 
> Koordinaten+Name mit "[out:csv(…)];". Also z.B. so:
>
> ---
>
> [out:csv(::lat, ::lon, name)];
> (
>   node[amenity=nursing_home]({{bbox}});
>   way[amenity=nursing_home]({{bbox}});
>   relation[type=multipolygon][amenity=nursing_home]({{bbox}});
> );
> out center;
>
> ---
>
> amenity=nursing_home ist allerdings deprecated, um alle Altenheime zu 
> bekommen, müsstest du das Query auch noch auf social_facility=nursing_home 
> etc. ausdehnen.
>
> Viele Grüße
> Christoph
>
> Am Sonntag, 27. Januar 2019, 23:33:08 schrieb Martin Scholtes:
>> Nabend zusammen,
>>
>> ich hätte da mal ein Anliegen an die Overpass Kenner:
>> Ich würde gerne ein Abfrage zu, zum Bsp. Altenheime,  starten und
>> folgende Daten Ausgeben: Koordinaten und Name. Dabei sollen bei POI´s
>> und Relationen der Mittelpunkt genommen werden.
>>
>> Kann man das i-wie als Code schreiben.
>>
>> Schönen Abend.
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [Talk-de] Overpass Abfrage

[Stefan Keller]

Hi,

> Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> > [out:csv(::lat, ::lon, name)];

Was ich mich schon lange frage bzw. wünsche ist, dass auch bei anderen
Output-Formaten als CSV (also den out settings xml,json,custom,popup)
die Rückgabe-Attribute eingeschränkt werden könnten.

Also z.B. so
[out:json(::lat, ::lon, name)];

Hab' grad nix in den Issues dazu gefunden.
Soll ich einen Issue machen auf [1]?

:Stefan

[1] 
https://github.com/drolbr/Overpass-API/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+output


Am Mo., 28. Jan. 2019 um 00:19 Uhr schrieb Martin Scholtes
:
>
> Hallo Christoph,
>
> super danke für deine Antwort ;-)
>
> Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> > [out:csv(::lat, ::lon, name)];
> > (
> >   node[amenity=nursing_home]({{bbox}});
> >   way[amenity=nursing_home]({{bbox}});
> >   relation[type=multipolygon][amenity=nursing_home]({{bbox}});
> > );
> > out center;
>
> --
> Mit freundlichen Grüßen
>
>
> Martin Scholtes
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

Perhaps OSM UK could step in and endorse address tagging practices once a 
consensus is reached? In the end it does not matter what tag names we use as 
long as the whole scheme is consistent and rich enough to describe common use 
cases. 

So far, I see addr:city=posttown is a popular solution, which I am happy about. 
But it would have to go with something like addr:town/village to denote 
dependent localities. Otherwise we won't be able to convince mappers from 
smaller towns to follow this convention. 

Another idea, if we allowed addr:place and addr:street to be used together, 
addr:place could be used as "dependent thoroughfare" with no(?) other changes. 

Best wishes, 
Andrzej 



On 28 January 2019 06:48:11 GMT+08:00, Colin Smale  
wrote:
>David, thanks for offering some updates. 
>
>By the way, I am not asking questions because I personally want the
>answers - I am fully aware of how these things work. And because of
>that, and because OSM tries to model reality, I believe we need some
>kind of anchor-point for our thinking in order to converge on a proper
>solution. In many countries postcodes/zip codes are associated with
>geographic areas; the UK, as frequently happens, uses a different
>paradigm. We need a clear statement of the intention for the addresses
>in OSM, and my belief is that they represent postal addresses as per
>the
>PAF. PO Box numbers are not applicable to OSM, as they cannot be
>related
>to a location useful in OSM. The discussion is just about Dependent
>Locaiity, Double Dependent Locality, and Dependent Thoroughfare. If we
>can define what OSM tag should be used for these three fields, we have
>a
>model which is sufficient for all UK addresses. 
>
>Of course, it is an option to decide to NOT represent this level of
>detail in OSM. In that case, expect mappers to make up their own
>solutions, and this discussion to resurface every few months. 
>
>Next iteration: 
>
>   ELEMENT
>   FIELD NAME
>   DESCRIPTION
>   MAX LENGTH
>   OSM
>
>   Organisation
>   Organisation Name
>
>   60
>   n/a
>
>   Department Name
>
>   60
>   n/a
>
>   Premises
>   Sub Building Name
>
>   30
>   addr:unit
>
>   Building Name
>
>   50
>   addr:housename
>
>   Building Number
>
>   4
>   addr:housenumber
>
>   Thoroughfare
>   Dependent Thoroughfare Name
>
>   60
>
>   Dependent Thoroughfare Descriptor
>
>   20
>
>   Thoroughfare Name
>   Street
>   60
>   addr:street
>
>   Thoroughfare Descriptor
>
>   20
>   addr:street
>
>   Locality
>   Double Dependent Locality
>   Small villages
>   35
>
>   Dependent Locality
>
>   35
>
>   Post town
>
>   30
>   addr:city
>
>   Postcode
>   Postcode
>
>   7
>   addr:postcode
>
>   PO Box
>   PO Box
>
>   6
>n/a
>
>On 2019-01-27 23:17, David Woolley wrote:
>
>> On 27/01/2019 21:21, Colin Smale wrote: 
>> 
>>> Organisation Organisation Name 60 n/a
>>> Department Name 60 n/a
>>> Premises Sub Building Name 30
>> 
>> addr:unit
>> 
>>> Building Name 50 addr:housename
>>> Building Number 4 addr:housenumber
>>> Thoroughfare Dependent Thoroughfare Name 60
>> 
>> This is the one that actually normally causes questions.  It is quite
>common to have named terraces, and to have runs of maisonettes numbered
>within a name.
>> 
>>> Dependent Thoroughfare Descriptor 20 Thoroughfare Name
>Street 60 addr:street
>>> Thoroughfare Descriptor 20 Locality Double Dependent
>Locality Small villages 35 Dependent Locality 35 Post
>town 30 addr:city
>> 
>> Firstly, addr in OSM is generally postal, not geographical.  As
>indicated elsewhere containment (or is_in) define the geographical
>place.
>> 
>> Secondly, in practice the only parts of the address you need are the
>detailed destination point code and the post code.  However, I
>discovered that the postie on the beat also needs the street name to
>avoid having to look it up from the postcode.
>> 
>> The bar codes for Walksort only contain the postcode and two
>character detailed destination.  (Is there a potential project there,
>to capture these.  Everyone who has received utility bills will have
>their own code, but they are only available to paying customers, as far
>as the sender is concerned.)
>> 
>>> Postcode Postcode 7 addr:postcode
>>> PO Box PO Box 6
>> 
>> 

Re: [Talk-de] Overpass Abfrage

[Martin Scholtes]

Hallo Christoph,

super danke für deine Antwort ;-)

Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> [out:csv(::lat, ::lon, name)];
> (
>   node[amenity=nursing_home]({{bbox}});
>   way[amenity=nursing_home]({{bbox}});
>   relation[type=multipolygon][amenity=nursing_home]({{bbox}});
> );
> out center;

-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [Talk-de] Overpass Abfrage

[Christoph Grenz]

Hallo Martin,

du bekommst dem Mittelpunkt bei POIs mit "out center" und die Ausgabe 
Koordinaten+Name mit "[out:csv(…)];". Also z.B. so:

---

[out:csv(::lat, ::lon, name)];
(
node[amenity=nursing_home]({{bbox}});
way[amenity=nursing_home]({{bbox}});
relation[type=multipolygon][amenity=nursing_home]({{bbox}});
);
out center;

---

amenity=nursing_home ist allerdings deprecated, um alle Altenheime zu 
bekommen, müsstest du das Query auch noch auf social_facility=nursing_home 
etc. ausdehnen.

Viele Grüße
Christoph

Am Sonntag, 27. Januar 2019, 23:33:08 schrieb Martin Scholtes:
> Nabend zusammen,
> 
> ich hätte da mal ein Anliegen an die Overpass Kenner:
> Ich würde gerne ein Abfrage zu, zum Bsp. Altenheime,  starten und
> folgende Daten Ausgeben: Koordinaten und Name. Dabei sollen bei POI´s
> und Relationen der Mittelpunkt genommen werden.
> 
> Kann man das i-wie als Code schreiben.
> 
> Schönen Abend.


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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Colin Smale]

Hi Andrezej,

I would oppose addr:village for the Dependent Locality as it invites
incorrect usage. There is no reason to overload an existing tag with a
different meaning to its current usage. In the UK, a village is not
simply a neat subdivision of a town. I think addr:locality and
addr:sublocality would be better, as this would (correctly) imply a
possibly fuzzy boundary which possibly crosses formal admin boundaries. 

Regarding streets/thoroughfares, the main thoroughfare is addr:street -
that is clear and established usage. We are looking for a solution for a
"substreet" and moving the main thoroughfare up to "addr:parentstreet"
to make room for the dependent thoroughfare in "addr:street" feels wrong
as it gives addr:street different semantics under some conditions. Note
also that the word "thoroughfare" has probably been carefully chosen to
allow application to things other than simple streets with adresses
neatly on each side. I would also instinctively expect a campus to be
more of a locality (subarea of a Town) than a super-street. Maybe
someone with access to PAF data can see what data is in what fields for
some address on the CSP. 

It wouldn't surprise me if subbuildings were used for "Unit 1",
"Building A" etc. That doesn't sound/feel at all unreasonable. 

On 2019-01-27 23:27, Andrzej wrote:

> Hi Colin,
> 
> This is broadly in line with Robert's proposals. However, it raises questions 
> about:
> 
> 1. tagging "dependent localities" - they can be towns or villages. Are you 
> happy with addr:town, addr:village for this purpose? Reaching consensus on 
> that would be a major step forward. 
> 
> 2. Tagging "dependent throughfares". I think they could be used to tag 
> "building name, Cambridge Science Park, Milton Road, Cambridge". This could 
> be addr:place except in OSM addr:place should not be combined with 
> addr:street. Or, like in Robert's proposal, addr:street+addr:parentstreet. 
> Except that CSP is a campus, not a street. 
> 
> 3. Tagging subbuildings. Addr:unit is available but is fairly limited (unit 
> names?) and vague. 
> 
> 4. PO Box - I haven't thought about it. Is that something that we would 
> include at all in a geographical database? Perhaps if it is associated with a 
> business that has a known location but uses PO Box as its address? 
> 
> Best wishes,
> Andrzej 
> 
> On 28 January 2019 05:21:36 GMT+08:00, Colin Smale  
> wrote: 
> 
> Assuming the post code is seen in OSM as a way of addressing post (as opposed 
> to a geographic subdivision or an indication of location) then I suggest 
> following Royal Mail's address structure, which can be seen in the 
> description of the Postcode Address File on Wikipedia [1]. If we cannot map a 
> full-format address onto OSM tags, we need a description of how to deal with 
> this (i.e. which bits to leave out or combine). 
> 
> I have taken the table from wikipedia and added a column for the OSM tags 
> where known. Most of these fields are actually optional, or not always 
> present, depending on the exact address in question. 
> 
> How do we fill in the blanks? 
> 
> ELEMENT
> FIELD NAME
> DESCRIPTION
> MAX LENGTH
> OSM
> 
> Organisation
> Organisation Name
> 
> 60
> n/a
> 
> Department Name
> 
> 60
> n/a
> 
> Premises
> Sub Building Name
> 
> 30
> 
> Building Name
> 
> 50
> addr:housename
> 
> Building Number
> 
> 4
> addr:housenumber
> 
> Thoroughfare
> Dependent Thoroughfare Name
> 
> 60
> 
> Dependent Thoroughfare Descriptor
> 
> 20
> 
> Thoroughfare Name
> Street
> 60
> addr:street
> 
> Thoroughfare Descriptor
> 
> 20
> 
> Locality
> Double Dependent Locality
> Small villages
> 35
> 
> Dependent Locality
> 
> 35
> 
> Post town
> 
> 30
> addr:city
> 
> Postcode
> Postcode
> 
> 7
> addr:postcode
> 
> PO Box
> PO Box
> 
> 6
> 
> [1] https://en.wikipedia.org/wiki/Postcode_Address_File 
> 
> On 2019-01-27 21:40, Andrzej wrote: 
> 
> Hi,
> 
> When working on post codes in East Anglia I realised the current address 
> tagging scheme is insufficient for even fairly basic scenarios. I have 
> already discussed the issues with some of the most experienced mappers and 
> like to bring these issues to your attention. Robert has summarised his ideas 
> in https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping
> 
> The bottom line is, I would like to be tag commonly used addresses without 
> losing information and without resorting to addr:full. 
> 
> Issues:
> 1. Post towns (most pressing one because there is a lot of confusion around 
> it). The UK is fairly unique in that not every town is a post town. This 
> makes it impossible to tag e.g. Station Road, Histon, Cambridge CB24 9LF. 
> Wiki recommends addr:city to be used for tagging post towns (Cambridge) but 
> then how do we tag Histon? 
> - Robert recommends sticking to the current meaning of addr:city and using 
> addr:town and addr:village for town and village names, which, although not in 
> wiki, are already being used in the UK. I like this solution because it 

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

On 28 January 2019 06:17:04 GMT+08:00, David Woolley 
 wrote:
>On 27/01/2019 21:21, Colin Smale wrote:
>> Organisation Organisation Name   60  n/a
>> Department Name  60  n/a
>> Premises Sub Building Name   30  
>
>addr:unit

What about the Sub Building Name? 

>> Building Name50  addr:housename
>> Building Number  4   addr:housenumber
>> Thoroughfare Dependent Thoroughfare Name 60  
>
>This is the one that actually normally causes questions.  It is quite 
>common to have named terraces, and to have runs of maisonettes numbered
>within a name.

Good point.I would also add campuses in this category. Although I am not 100% 
sure if that's how they are classified in PAF. 

>> Dependent Thoroughfare Descriptor20  
>> Thoroughfare NameStreet  60  addr:street
>> Thoroughfare Descriptor  20  
>> Locality Double Dependent Locality   Small villages  35  
>> Dependent Locality   35  
>> Post town30  addr:city
>
>Firstly, addr in OSM is generally postal, not geographical.  As 
>indicated elsewhere containment (or is_in) define the geographical
>place. 

True, but full address would still include extra information. We can infer 
addr:country and addr:county from admin areas but everything else should be 
_possible_ to tag. 

>Secondly, in practice the only parts of the address you need are the 
>detailed destination point code and the post code.  However, I 
>discovered that the postie on the beat also needs the street name to 
>avoid having to look it up from the postcode.

It should still be possible to encode a typical full address with tags. 
Sometimes people will want extract the full address from OSM, sometimes they 
will want to search for a part of it. Even if someone is searching for a house 
number and a postcode alone it is useful to see if e.g. a street name of the 
result matches expectations. 

Best wishes,
Andrzej

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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Colin Smale]

David, thanks for offering some updates. 

By the way, I am not asking questions because I personally want the
answers - I am fully aware of how these things work. And because of
that, and because OSM tries to model reality, I believe we need some
kind of anchor-point for our thinking in order to converge on a proper
solution. In many countries postcodes/zip codes are associated with
geographic areas; the UK, as frequently happens, uses a different
paradigm. We need a clear statement of the intention for the addresses
in OSM, and my belief is that they represent postal addresses as per the
PAF. PO Box numbers are not applicable to OSM, as they cannot be related
to a location useful in OSM. The discussion is just about Dependent
Locaiity, Double Dependent Locality, and Dependent Thoroughfare. If we
can define what OSM tag should be used for these three fields, we have a
model which is sufficient for all UK addresses. 

Of course, it is an option to decide to NOT represent this level of
detail in OSM. In that case, expect mappers to make up their own
solutions, and this discussion to resurface every few months. 

Next iteration: 

ELEMENT
FIELD NAME
DESCRIPTION
MAX LENGTH
OSM

Organisation
Organisation Name

60
n/a

Department Name

60
n/a

Premises
Sub Building Name

30
addr:unit

Building Name

50
addr:housename

Building Number

4
addr:housenumber

Thoroughfare
Dependent Thoroughfare Name

60

Dependent Thoroughfare Descriptor

20

Thoroughfare Name
Street
60
addr:street

Thoroughfare Descriptor

20
addr:street

Locality
Double Dependent Locality
Small villages
35

Dependent Locality

35

Post town

30
addr:city

Postcode
Postcode

7
addr:postcode

PO Box
PO Box

6
 n/a

On 2019-01-27 23:17, David Woolley wrote:

> On 27/01/2019 21:21, Colin Smale wrote: 
> 
>> Organisation Organisation Name 60 n/a
>> Department Name 60 n/a
>> Premises Sub Building Name 30
> 
> addr:unit
> 
>> Building Name 50 addr:housename
>> Building Number 4 addr:housenumber
>> Thoroughfare Dependent Thoroughfare Name 60
> 
> This is the one that actually normally causes questions.  It is quite common 
> to have named terraces, and to have runs of maisonettes numbered within a 
> name.
> 
>> Dependent Thoroughfare Descriptor 20 Thoroughfare Name Street
>>  60 addr:street
>> Thoroughfare Descriptor 20 Locality Double Dependent Locality
>>  Small villages 35 Dependent Locality 35 Post town 30
>>  addr:city
> 
> Firstly, addr in OSM is generally postal, not geographical.  As indicated 
> elsewhere containment (or is_in) define the geographical place.
> 
> Secondly, in practice the only parts of the address you need are the detailed 
> destination point code and the post code.  However, I discovered that the 
> postie on the beat also needs the street name to avoid having to look it up 
> from the postcode.
> 
> The bar codes for Walksort only contain the postcode and two character 
> detailed destination.  (Is there a potential project there, to capture these. 
>  Everyone who has received utility bills will have their own code, but they 
> are only available to paying customers, as far as the sender is concerned.)
> 
>> Postcode Postcode 7 addr:postcode
>> PO Box PO Box 6
> 
> PO Box is not really relevant.  In most cases it is attached to a post office 
> building. 
> 
>> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-de] Overpass Abfrage

[Martin Scholtes]

Nabend zusammen,

ich hätte da mal ein Anliegen an die Overpass Kenner:
Ich würde gerne ein Abfrage zu, zum Bsp. Altenheime,  starten und
folgende Daten Ausgeben: Koordinaten und Name. Dabei sollen bei POI´s
und Relationen der Mittelpunkt genommen werden.

Kann man das i-wie als Code schreiben.

Schönen Abend.

-- 
Mit freundlichen Grüßen


Martin Scholtes


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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

At low level (commercial areas, academic campuses, hospitals) that's not really 
the case. They are not as formalised as admin areas.

Best wishes,
Andrzej 

On 28 January 2019 05:46:23 GMT+08:00, Gareth L  wrote:
>I’d hope these would inherit from whatever the address is enclosed in.
>
>On 27 Jan 2019, at 21:22, Colin Smale
>mailto:colin.sm...@xs4all.nl>> wrote:
>
>
>Assuming the post code is seen in OSM as a way of addressing post (as
>opposed to a geographic subdivision or an indication of location) then
>I suggest following Royal Mail's address structure, which can be seen
>in the description of the Postcode Address File on Wikipedia [1]. If we
>cannot map a full-format address onto OSM tags, we need a description
>of how to deal with this (i.e. which bits to leave out or combine).
>
>I have taken the table from wikipedia and added a column for the OSM
>tags where known. Most of these fields are actually optional, or not
>always present, depending on the exact address in question.
>
>How do we fill in the blanks?
>
>
>Element Field name  Description Max length  OSM
>OrganisationOrganisation Name   60  n/a
>Department Name 60  n/a
>PremisesSub Building Name   30
>Building Name   50  addr:housename
>Building Number 4   addr:housenumber
>ThoroughfareDependent Thoroughfare Name 60
>Dependent Thoroughfare Descriptor   20
>Thoroughfare Name   Street  60  addr:street
>Thoroughfare Descriptor 20
>LocalityDouble Dependent Locality   Small villages  35
>Dependent Locality  35
>Post town   30  addr:city
>PostcodePostcode7   addr:postcode
>PO Box  PO Box  6
>
>
>
>[1] https://en.wikipedia.org/wiki/Postcode_Address_File
>
>
>
>
>On 2019-01-27 21:40, Andrzej wrote:
>
>Hi,
>
>When working on post codes in East Anglia I realised the current
>address tagging scheme is insufficient for even fairly basic scenarios.
>I have already discussed the issues with some of the most experienced
>mappers and like to bring these issues to your attention. Robert has
>summarised his ideas in
>https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping
>
>The bottom line is, I would like to be tag commonly used addresses
>without losing information and without resorting to addr:full.
>
>Issues:
>1. Post towns (most pressing one because there is a lot of confusion
>around it). The UK is fairly unique in that not every town is a post
>town. This makes it impossible to tag e.g. Station Road, Histon,
>Cambridge CB24 9LF.
>Wiki recommends addr:city to be used for tagging post towns (Cambridge)
>but then how do we tag Histon?
>- Robert recommends sticking to the current meaning of addr:city and
>using addr:town and addr:village for town and village names, which,
>although not in wiki, are already being used in the UK. I like this
>solution because it is very explicit in what each addr: key means and
>it doesn't redefine addr:city.
>- SK53 prefers using addr:city for everything (towns, even villages)
>and either not tagging post towns (they can be seen as a an internal
>detail of a closed Royal Mail database) or using a new tag for it, like
>addr:post_town. It is a simple solution, results in Histon being called
>Histon and not Cambridge (without introducing new tags for town and
>village names) and is commonly used. It is also a bit confusing (what
>exactly is a city?) and I think we we should at least support tagging
>post towns.
>
>Key questions:
>a) addr:city for post towns or towns and villages?
>b) how to rag remaining information (respectively, towns and villages
>or post towns,)
>
>2. Tagging addresses within campuses, business parks etc. There is
>addr:place but it is supposed to be used instead of addr:street. Again,
>Robert has a fairly decent proposal for that using addr:place or
>addr:locality and addr:parentstreet. Please comment.
>
>2a. should buildings in campuses be tagged with
>addr:buildingnumber/name or addr:unit? I would prefer
>buildingname/number (as they are often subdivided) but these seem to be
>associated with addr:street.
>
>3. Similar to (2) but for buildings. Tagging buildings that have e.g. a
>single name but multiple house numbers?
>
>Best regards,
>ndrw6
>
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

Hi Colin,

This is broadly in line with Robert's proposals. However, it raises questions 
about:

1. tagging "dependent localities" - they can be towns or villages. Are you 
happy with addr:town, addr:village for this purpose? Reaching consensus on that 
would be a major step forward. 

2. Tagging "dependent throughfares". I think they could be used to tag 
"building name, Cambridge Science Park, Milton Road, Cambridge". This could be 
addr:place except in OSM addr:place should not be combined with addr:street. 
Or, like in Robert's proposal, addr:street+addr:parentstreet. Except that CSP 
is a campus, not a street. 

3. Tagging subbuildings. Addr:unit is available but is fairly limited (unit 
names?) and vague. 

4. PO Box - I haven't thought about it. Is that something that we would include 
at all in a geographical database? Perhaps if it is associated with a business 
that has a known location but uses PO Box as its address? 

Best wishes,
Andrzej 

On 28 January 2019 05:21:36 GMT+08:00, Colin Smale  
wrote:
>Assuming the post code is seen in OSM as a way of addressing post (as
>opposed to a geographic subdivision or an indication of location) then
>I
>suggest following Royal Mail's address structure, which can be seen in
>the description of the Postcode Address File on Wikipedia [1]. If we
>cannot map a full-format address onto OSM tags, we need a description
>of
>how to deal with this (i.e. which bits to leave out or combine). 
>
>I have taken the table from wikipedia and added a column for the OSM
>tags where known. Most of these fields are actually optional, or not
>always present, depending on the exact address in question. 
>
>How do we fill in the blanks? 
>
>   ELEMENT
>   FIELD NAME
>   DESCRIPTION
>   MAX LENGTH
>   OSM
>
>   Organisation
>   Organisation Name
>
>   60
>   n/a
>
>   Department Name
>
>   60
>   n/a
>
>   Premises
>   Sub Building Name
>
>   30
>
>   Building Name
>
>   50
>   addr:housename
>
>   Building Number
>
>   4
>   addr:housenumber
>
>   Thoroughfare
>   Dependent Thoroughfare Name
>
>   60
>
>   Dependent Thoroughfare Descriptor
>
>   20
>
>   Thoroughfare Name
>   Street
>   60
>   addr:street
>
>   Thoroughfare Descriptor
>
>   20
>
>   Locality
>   Double Dependent Locality
>   Small villages
>   35
>
>   Dependent Locality
>
>   35
>
>   Post town
>
>   30
>   addr:city
>
>   Postcode
>   Postcode
>
>   7
>   addr:postcode
>
>   PO Box
>   PO Box
>
>   6
>
>[1] https://en.wikipedia.org/wiki/Postcode_Address_File 
>
>On 2019-01-27 21:40, Andrzej wrote:
>
>> Hi,
>> 
>> When working on post codes in East Anglia I realised the current
>address tagging scheme is insufficient for even fairly basic scenarios.
>I have already discussed the issues with some of the most experienced
>mappers and like to bring these issues to your attention. Robert has
>summarised his ideas in
>https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping
>> 
>> The bottom line is, I would like to be tag commonly used addresses
>without losing information and without resorting to addr:full. 
>> 
>> Issues:
>> 1. Post towns (most pressing one because there is a lot of confusion
>around it). The UK is fairly unique in that not every town is a post
>town. This makes it impossible to tag e.g. Station Road, Histon,
>Cambridge CB24 9LF. 
>> Wiki recommends addr:city to be used for tagging post towns
>(Cambridge) but then how do we tag Histon? 
>> - Robert recommends sticking to the current meaning of addr:city and
>using addr:town and addr:village for town and village names, which,
>although not in wiki, are already being used in the UK. I like this
>solution because it is very explicit in what each addr: key means and
>it doesn't redefine addr:city. 
>> - SK53 prefers using addr:city for everything (towns, even villages)
>and either not tagging post towns (they can be seen as a an internal
>detail of a closed Royal Mail database) or using a new tag for it, like
>addr:post_town. It is a simple solution, results in Histon being called
>Histon and not Cambridge (without introducing new tags for town and
>village names) and is commonly used. It is also a bit confusing (what
>exactly is a city?) and I think we we should at least support tagging
>post towns. 
>> 
>> Key questions:
>> a) addr:city for post towns or towns and villages? 
>> b) how to rag remaining information (respectively, towns and villages
>or post towns,) 
>> 
>> 

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[David Woolley]

On 27/01/2019 21:21, Colin Smale wrote:

OrganisationOrganisation Name   60  n/a
Department Name 60  n/a
PremisesSub Building Name   30  


addr:unit


Building Name   50  addr:housename
Building Number 4   addr:housenumber
ThoroughfareDependent Thoroughfare Name 60  


This is the one that actually normally causes questions.  It is quite 
common to have named terraces, and to have runs of maisonettes numbered 
within a name.



Dependent Thoroughfare Descriptor   20  
Thoroughfare Name   Street  60  addr:street
Thoroughfare Descriptor 20  
LocalityDouble Dependent Locality   Small villages  35  
Dependent Locality  35  
Post town   30  addr:city


Firstly, addr in OSM is generally postal, not geographical.  As 
indicated elsewhere containment (or is_in) define the geographical place.


Secondly, in practice the only parts of the address you need are the 
detailed destination point code and the post code.  However, I 
discovered that the postie on the beat also needs the street name to 
avoid having to look it up from the postcode.


The bar codes for Walksort only contain the postcode and two character 
detailed destination.  (Is there a potential project there, to capture 
these.  Everyone who has received utility bills will have their own 
code, but they are only available to paying customers, as far as the 
sender is concerned.)



PostcodePostcode7   addr:postcode
PO Box  PO Box  6   


PO Box is not really relevant.  In most cases it is attached to a post 
office building.






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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Gareth L]

I’d hope these would inherit from whatever the address is enclosed in.

On 27 Jan 2019, at 21:22, Colin Smale 
mailto:colin.sm...@xs4all.nl>> wrote:


Assuming the post code is seen in OSM as a way of addressing post (as opposed 
to a geographic subdivision or an indication of location) then I suggest 
following Royal Mail's address structure, which can be seen in the description 
of the Postcode Address File on Wikipedia [1]. If we cannot map a full-format 
address onto OSM tags, we need a description of how to deal with this (i.e. 
which bits to leave out or combine).

I have taken the table from wikipedia and added a column for the OSM tags where 
known. Most of these fields are actually optional, or not always present, 
depending on the exact address in question.

How do we fill in the blanks?


Element Field name  Description Max length  OSM
OrganisationOrganisation Name   60  n/a
Department Name 60  n/a
PremisesSub Building Name   30
Building Name   50  addr:housename
Building Number 4   addr:housenumber
ThoroughfareDependent Thoroughfare Name 60
Dependent Thoroughfare Descriptor   20
Thoroughfare Name   Street  60  addr:street
Thoroughfare Descriptor 20
LocalityDouble Dependent Locality   Small villages  35
Dependent Locality  35
Post town   30  addr:city
PostcodePostcode7   addr:postcode
PO Box  PO Box  6



[1] https://en.wikipedia.org/wiki/Postcode_Address_File




On 2019-01-27 21:40, Andrzej wrote:

Hi,

When working on post codes in East Anglia I realised the current address 
tagging scheme is insufficient for even fairly basic scenarios. I have already 
discussed the issues with some of the most experienced mappers and like to 
bring these issues to your attention. Robert has summarised his ideas in 
https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping

The bottom line is, I would like to be tag commonly used addresses without 
losing information and without resorting to addr:full.

Issues:
1. Post towns (most pressing one because there is a lot of confusion around 
it). The UK is fairly unique in that not every town is a post town. This makes 
it impossible to tag e.g. Station Road, Histon, Cambridge CB24 9LF.
Wiki recommends addr:city to be used for tagging post towns (Cambridge) but 
then how do we tag Histon?
- Robert recommends sticking to the current meaning of addr:city and using 
addr:town and addr:village for town and village names, which, although not in 
wiki, are already being used in the UK. I like this solution because it is very 
explicit in what each addr: key means and it doesn't redefine addr:city.
- SK53 prefers using addr:city for everything (towns, even villages) and either 
not tagging post towns (they can be seen as a an internal detail of a closed 
Royal Mail database) or using a new tag for it, like addr:post_town. It is a 
simple solution, results in Histon being called Histon and not Cambridge 
(without introducing new tags for town and village names) and is commonly used. 
It is also a bit confusing (what exactly is a city?) and I think we we should 
at least support tagging post towns.

Key questions:
a) addr:city for post towns or towns and villages?
b) how to rag remaining information (respectively, towns and villages or post 
towns,)

2. Tagging addresses within campuses, business parks etc. There is addr:place 
but it is supposed to be used instead of addr:street. Again, Robert has a 
fairly decent proposal for that using addr:place or addr:locality and 
addr:parentstreet. Please comment.

2a. should buildings in campuses be tagged with addr:buildingnumber/name or 
addr:unit? I would prefer buildingname/number (as they are often subdivided) 
but these seem to be associated with addr:street.

3. Similar to (2) but for buildings. Tagging buildings that have e.g. a single 
name but multiple house numbers?

Best regards,
ndrw6


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

Re: [Talk-GB] Tagging post towns and other addressing issues in the UK

[Colin Smale]

Assuming the post code is seen in OSM as a way of addressing post (as
opposed to a geographic subdivision or an indication of location) then I
suggest following Royal Mail's address structure, which can be seen in
the description of the Postcode Address File on Wikipedia [1]. If we
cannot map a full-format address onto OSM tags, we need a description of
how to deal with this (i.e. which bits to leave out or combine). 

I have taken the table from wikipedia and added a column for the OSM
tags where known. Most of these fields are actually optional, or not
always present, depending on the exact address in question. 

How do we fill in the blanks? 

ELEMENT
FIELD NAME
DESCRIPTION
MAX LENGTH
OSM

Organisation
Organisation Name

60
n/a

Department Name

60
n/a

Premises
Sub Building Name

30

Building Name

50
addr:housename

Building Number

4
addr:housenumber

Thoroughfare
Dependent Thoroughfare Name

60

Dependent Thoroughfare Descriptor

20

Thoroughfare Name
Street
60
addr:street

Thoroughfare Descriptor

20

Locality
Double Dependent Locality
Small villages
35

Dependent Locality

35

Post town

30
addr:city

Postcode
Postcode

7
addr:postcode

PO Box
PO Box

6

[1] https://en.wikipedia.org/wiki/Postcode_Address_File 

On 2019-01-27 21:40, Andrzej wrote:

> Hi,
> 
> When working on post codes in East Anglia I realised the current address 
> tagging scheme is insufficient for even fairly basic scenarios. I have 
> already discussed the issues with some of the most experienced mappers and 
> like to bring these issues to your attention. Robert has summarised his ideas 
> in https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping
> 
> The bottom line is, I would like to be tag commonly used addresses without 
> losing information and without resorting to addr:full. 
> 
> Issues:
> 1. Post towns (most pressing one because there is a lot of confusion around 
> it). The UK is fairly unique in that not every town is a post town. This 
> makes it impossible to tag e.g. Station Road, Histon, Cambridge CB24 9LF. 
> Wiki recommends addr:city to be used for tagging post towns (Cambridge) but 
> then how do we tag Histon? 
> - Robert recommends sticking to the current meaning of addr:city and using 
> addr:town and addr:village for town and village names, which, although not in 
> wiki, are already being used in the UK. I like this solution because it is 
> very explicit in what each addr: key means and it doesn't redefine addr:city. 
> - SK53 prefers using addr:city for everything (towns, even villages) and 
> either not tagging post towns (they can be seen as a an internal detail of a 
> closed Royal Mail database) or using a new tag for it, like addr:post_town. 
> It is a simple solution, results in Histon being called Histon and not 
> Cambridge (without introducing new tags for town and village names) and is 
> commonly used. It is also a bit confusing (what exactly is a city?) and I 
> think we we should at least support tagging post towns. 
> 
> Key questions:
> a) addr:city for post towns or towns and villages? 
> b) how to rag remaining information (respectively, towns and villages or post 
> towns,) 
> 
> 2. Tagging addresses within campuses, business parks etc. There is addr:place 
> but it is supposed to be used instead of addr:street. Again, Robert has a 
> fairly decent proposal for that using addr:place or addr:locality and 
> addr:parentstreet. Please comment. 
> 
> 2a. should buildings in campuses be tagged with addr:buildingnumber/name or 
> addr:unit? I would prefer buildingname/number (as they are often subdivided) 
> but these seem to be associated with addr:street. 
> 
> 3. Similar to (2) but for buildings. Tagging buildings that have e.g. a 
> single name but multiple house numbers? 
> 
> Best regards, 
> ndrw6
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-us] NC sidewalk data import

[Melanie Mazanec]

Hello,

I'm a front end dev for a city government working on a side project to fork
and add to AccessMap  for North Carolina cities.

In order to make this happen, I want to import North Carolina city sidewalk
data into OSM.  I have no prior OSM experience, so I'm following the
suggested wiki protocol and reaching out here before attempting an import.

Does anyone have advice about tutorials or where to start?  Are there any
NC OSM communities or enthusiasts I can connect with?  Also, it seems like
there are two competing sidewalk data formats.  Is there a preferred
standard now?

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

[Talk-GB] Tagging post towns and other addressing issues in the UK

[Andrzej]

Hi,

When working on post codes in East Anglia I realised the current address 
tagging scheme is insufficient for even fairly basic scenarios. I have already 
discussed the issues with some of the most experienced mappers and like to 
bring these issues to your attention. Robert has summarised his ideas in 
https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping

The bottom line is, I would like to be tag commonly used addresses without 
losing information and without resorting to addr:full. 

Issues:
1. Post towns (most pressing one because there is a lot of confusion around 
it). The UK is fairly unique in that not every town is a post town. This makes 
it impossible to tag e.g. Station Road, Histon, Cambridge CB24 9LF. 
Wiki recommends addr:city to be used for tagging post towns (Cambridge) but 
then how do we tag Histon? 
- Robert recommends sticking to the current meaning of addr:city and using 
addr:town and addr:village for town and village names, which, although not in 
wiki, are already being used in the UK. I like this solution because it is very 
explicit in what each addr: key means and it doesn't redefine addr:city. 
- SK53 prefers using addr:city for everything (towns, even villages) and either 
not tagging post towns (they can be seen as a an internal detail of a closed 
Royal Mail database) or using a new tag for it, like addr:post_town. It is a 
simple solution, results in Histon being called Histon and not Cambridge 
(without introducing new tags for town and village names) and is commonly used. 
It is also a bit confusing (what exactly is a city?) and I think we we should 
at least support tagging post towns. 

Key questions:
a) addr:city for post towns or towns and villages? 
b) how to rag remaining information (respectively, towns and villages or post 
towns,) 

2. Tagging addresses within campuses, business parks etc. There is addr:place 
but it is supposed to be used instead of addr:street. Again, Robert has a 
fairly decent proposal for that using addr:place or addr:locality and 
addr:parentstreet. Please comment. 

2a. should buildings in campuses be tagged with addr:buildingnumber/name or 
addr:unit? I would prefer buildingname/number (as they are often subdivided) 
but these seem to be associated with addr:street. 

3. Similar to (2) but for buildings. Tagging buildings that have e.g. a single 
name but multiple house numbers? 

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

Re: [Talk-GB] Dropped or lowered kerbs

[Rob Nickerson]

Hi Andy,

It somewhat depends on what you are trying to map.

The kerb=* tag on the wiki page you linked to is for when mapping a
crossing. As shown on the second example on the page. you would create a
way that runs perpendicular to the highway at the point where a footpath
(or cyclepath) crosses the road. Add a crossing tag at the point where the
footway (or cycleway) intersects the road. Then add a node on the footway
(or cycleway) at the kerb and add the appropriate tag (kerb=lowered,
kerb=flush).

The barrier=kerb tag in JOSM is when you want to map the kerbside. You draw
this parallel to the road and add barrier=kerb to the way to indicate that
this is the kerb. If you like, you can then add height=* to the way.

I would suggest doing the former and skipping the latter unless you are
intending to create a super detail map (e.g. when mapping roads as areas
rather than just centre lines).

Of course the issue here is that, even the former suggests that you are
mapping the pavements parallel to the way as footways. Quite often we don't
bother adding that level of detail. I guess in that case you could just add
the kerb=lowered tag to the highway=crossing node (assuming it is a lowered
kerb on both sides of the road).

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

Re: [Talk-br] HOTOSM Tasking Manager - Barragem em Brumadinho

[Alexandre Oliveira]

Para armazenar as imagens, seria necessário somente um servidor, ou
teria que fazer alguma outra coisa com elas?

On 27/01/2019 08:51, Theo A wrote:
> Obrigada, estamos trabalhando nisso. Sabem se essa informação está
> armazenada em algum lugar? Se não conseguirmos armazená-la,  o público não
> terá condições de adicionar imagens manualmente
> 
> On Sat, 26 Jan 2019 at 23:29, Narcélio de Sá Pereira Filho <
> narceliosapere...@gmail.com> wrote:
> 
>> Prezado segue o link para download de uma Imagem PLEIADES de 50 cm de
>> resolução colorida RGB de 18-01-19 de Brumadinho. MG, Mina Corrego do
>> Feijão. Ortoretificada UTM WGS 84 Fuso 23 S GEOTIF , KMZ e ECW.
>> Ortoretificada com parâmetros orbitais. A mesma pode ser utilizada para o
>> pŕe-mapeamento da área do sinistro.
>> link:
>> http://www.engesat.com.br/sobre-brumadinho-mg-dia-25-01-19/
>>
>> Atenciosamente
>> *[image: cropped-logo_512.png]*
>>
>> *Narcélio de Sá*
>> Mestre em Geografia - UFC
>> Analista de Sistema de Informação Geográfica - CAGECE
>> Coordenador da comunidade QGIS Brasil 
>> www.narceliodesa.com
>> [image: Facebook]  
>> [image:
>> Twitter]  [image: Google Plus]
>> 
>>  [image: Youtube]  [image:
>> Linkedin] 
>>
>>
>> Em sáb, 26 de jan de 2019 às 18:03, Theo A 
>> escreveu:
>>
>>> Caros membros da OSM Brazil,
>>>
>>>
>>>
>>> O Humanitarian OpenStreetMap Team está consciente dos acontecimentos nas
>>> áreas ao redor da barragem em Brumadinho.
>>>
>>>
>>>
>>> Estamos em processo de criação de novas tasks no nosso Tasking Manager
>>> para ajudar nos esforços de recuperação. Nosso Tasking Manager, que poderá
>>> ser encontrado encontrado através do link https://tasks.hotosm.org/
>>> ,
>>> dirige os usuários para areas específicas que serão mapeadas no
>>> OpenStreetMaps, ajudando assim a coordenar os esforços de recuperação.
>>>
>>>
>>>
>>> Caso haja qualquer pergunta, por favor sintam-se à vontade para nos
>>> contactar: activat...@hotosm.org ou faça parte da conversa no nosso
>>> Slack: http://slack.hotosm.org/
>>> 
>>> .
>>>
>>>
>>>
>>> Obrigado com antecedência por suas contribuições.
>>>
>>>
>>>
>>> Cumprimentos,
>>>
>>> Humanitarian OpenStreetMap Team - Disaster Activation Coordination.
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
> 


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

[Talk-GB] Dropped or lowered kerbs

[Andy Mabbett]

I've been reading the wiki page:

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

and I'm no wiser on how to map a dropped (or "lowered") kerb.

I'm looking at a road which is mapped as a single way, without
separate pavements.

JOSM wants to add "barrier=kerb", but that would surely imply a
barrier /across/ the road?

Examples would be helpful, please.

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

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

[OSM-talk] Rendered boundary not present in data

[Markus]

Hello,

I've come across a boundary rendered on both OSM Carto and the
Humanitarian layer that isn't present in the OSM data:

https://www.openstreetmap.org/?mlat=47.50350=-3.13473#map=19/47.50350/-3.13473=D

The correct boundary, which is present in the data, is also rendered:

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

(Note that the incorrect boundary was already rendered before my
recent edit to the correct one.)

Any idea where that ghost boundary might come from?

Thanks in advance for your help.

Regards

Markus

PS: I hope that this is the right mailing list for this kind of problem.

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

Wochennotiz Nr. 444 15.01.2019–21.01.2019

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 444 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2019/01/wochennotiz-nr-444/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[talk-cz] Jizdni rady was Re: Praha zveřejnila otevřená data o MHD

[Pavel Machek]

Ahoj!

> https://pid.cz/o-systemu/opendata/
> 
> Data, která lze stáhnout přímo zde z webu, jsou stejně jako celý obsah webu
> opatřena licencí *CC-BY *,
> tedy je lze dále šířit, avšak je nutné uvést autora a případné provedené
> změny. Data, která lze stáhnout z jiných zdrojů zde odkazovaných, se řídí
> licencí daného zdroje.

Tak ozivuju konverzni skripty... a oni celkem chodi; podarilo se mi
urychlit konverzi z gtfs.

Zakladni hledacka (timetab) nehleda uplne rozumna spojeni, ale je
rychla, funguje a ukazuje ze data jsou pouzitelna.

Martinuv travel taky nejak funguje, jen nevim jestli bere v uvahu dny
v tydnu.

Jak vse rozchodit a co to umi je videt tady:

https://gitlab.com/tui/tui/blob/master/timetab/cz/data/Makefile

Kdyby nekdo chtel pomoct, budu rad :-).

Mejte se,

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

[Talk-us] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] Building Import update

[john whelan]

If you take a look at 942 Bridle Path Crescent for example whilst it isn't
exactly square the deviations from 90 degrees to me are relatively minor.
I assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308

Are we expecting too high a standard?

Cheerio John

On Sat, 26 Jan 2019 at 21:54, Pierre Béland via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> Nate je viens juste de publier les résultats pour Kingston. Un ratio de
> 66% de polygones avec formes irrégulières. A voir si la simplification
> éliminerait les noeuds qui ont pour effet de créer des formes irrégulières.
>
> Je n'ai pas encore regardé de près les résultats. Cependant, m on
> expérience en République démocratique du Congo depuis l'an dernier, Kisenso
> et récemment Butembo, a montré qu'a partir de ces diagostics, la validation
> / correction si nécessaire des polygones permettait de réduire fortement
> les ratios, et ce sous les 3% des bâtiments.
>
> Je pense aussi qu'il faut prendre le temps de corriger les données qui
> risque de ne pas être modifiées par la suite.
>
>
>
> Pierre
>
>
> Le samedi 26 janvier 2019 21 h 06 min 39 s HNE, Nate Wessel <
> bike...@gmail.com> a écrit :
>
>
> James,
>
> It does seem that someone will need to properly simplify the data since
> you don't seem willing to do the necessary work. I've already offered to
> help, but I can't do it today, or tomorrow for that matter. My suggestion,
> again, is that we slow down and take the time to do this right. Rushing
> ahead can only lead to hurt feelings, angry emails, and extra work for
> everyone. Given how much editing goes on in the areas I know, many of these
> imported buildings might not be touched again for another decade - can't we
> make them right the first time?
>
> I think Pierre is on the right track here with his thoughtful analysis of
> the buildings that have been imported so far - this is the kind of stuff
> that I'm talking about when I say we need some validation. Some questions
> that I'd like to see answered (Pierre, when you have some more time!): just
> how many buildings imported so far are not orthogonal, but seem like they
> should be? What percentage of buildings would benefit from simplification,
> and is the problem worse/better in some areas compared to others?
>
> I actually don't think the problem is technically difficult to solve - we
> just have to understand the nature and extent off the problem before we
> rush to solutions. That's the point of validation - understanding what the
> problems are.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Bug JOSM avec gros fichiers du cadastre

[Vincent Privat]

Merci, j'arrive effectivement à reproduire le bug avec ce fichier.

Le sam. 26 janv. 2019 à 08:01, Gautier Pelloux-Prayer via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Vu la position de l'exception, il semblerait que ce soit Marseille 8eme :
> http://cadastre.openstreetmap.fr/data/013/80208-MARSEILLE%208EME-houses.osm
>
> A+
>
> Le 25 janvier 2019 23:46:02 GMT+01:00, Vincent Privat <
> vincent.pri...@gmail.com> a écrit :
>>
>> Hello,
>> Si la personne anonyme qui a créé ce bug me lit sur talk-fr:
>> https://josm.openstreetmap.de/ticket/17242
>>
>> J'aurais besoin du fichier .osm.
>> Merci,
>> 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: [Talk-GB] Mapping Driving Test Centres

[Mike Baggaley]

You could also add government=transportation to office=government

Regards,
Mike



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

Re: [Talk-GB] Mapping Driving Test Centres

[Brian Prangle]

You might want to add operator=DVSA. I tag them like Tony too

On Sat, 26 Jan 2019 at 23:04, Silent Spike  wrote:

> Thanks Tony, as the only reply here so far I've followed your approach.
>
> Could be valuable in future to develop a tagging scheme for these centres
> as they each do testing for different types of license, etc.
>
> Cheers
>
> On Sat, Jan 26, 2019 at 9:47 AM Tony Shield 
> wrote:
>
>> Hi
>>
>> Had same problem earlier. I gave a node (5490954973) within the
>> building=office outline
>>
>> office=government
>>
>> name=Chorley Driving Test Centre
>>
>> Regards
>>
>> TonyS999
>> On 25/01/2019 22:06, Silent Spike wrote:
>>
>> Searching the wiki I can't find anything that feels right for mapping
>> driving test centres.
>>
>> If anyone has mapped these in the past I'd be curious to know how you
>> tagged them (both practical and theory test centres).
>>
>> Also curious as to how they've been named (if at all) as the DVSA just
>> refers to them by where they are located.
>>
>> Cheers
>>
>> ___
>> Talk-GB mailing 
>> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-br] semanárioOSM Nº 444 2019-01-15-2019-01-21

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 444, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/11389/

Aproveite!

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-pt] semanárioOSM Nº 444 2019-01-15-2019-01-21

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 444, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/11389/

Aproveite!

semanarioOSM? 
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[OSM-co] semanarioOSM Nº 444 2019-01-15-2019-01-21

[theweekly . osm]

Hola, el semanario Nº 444, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/11389/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[Talk-cl] semanarioOSM Nº 444 2019-01-15-2019-01-21

[theweekly . osm]

Hola, el semanario Nº 444, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/11389/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[talk-latam] semanarioOSM Nº 444 2019-01-15-2019-01-21

[theweekly . osm]

Hola, el semanario Nº 444, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/11389/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-ko] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

매주 일어나는 OSM 소식을 종합한, 444번째 주간OSM이 발행되었습니다.

http://www.weeklyosm.eu/ko/archives/11389/

읽어 주셔서 감사합니다!

주간OSM이란? 
누가?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
어디서?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

[OSM-talk] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-GB] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-ca] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-africa] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[Talk-in] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[talk-ph] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-talk-ie] weeklyOSM #444 2019-01-15-2019-01-21

[weeklyteam]

The weekly round-up of OSM news, issue # 444,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11389/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-br] HOTOSM Tasking Manager - Barragem em Brumadinho

[Theo A]

Obrigada, estamos trabalhando nisso. Sabem se essa informação está
armazenada em algum lugar? Se não conseguirmos armazená-la,  o público não
terá condições de adicionar imagens manualmente

On Sat, 26 Jan 2019 at 23:29, Narcélio de Sá Pereira Filho <
narceliosapere...@gmail.com> wrote:

> Prezado segue o link para download de uma Imagem PLEIADES de 50 cm de
> resolução colorida RGB de 18-01-19 de Brumadinho. MG, Mina Corrego do
> Feijão. Ortoretificada UTM WGS 84 Fuso 23 S GEOTIF , KMZ e ECW.
> Ortoretificada com parâmetros orbitais. A mesma pode ser utilizada para o
> pŕe-mapeamento da área do sinistro.
> link:
> http://www.engesat.com.br/sobre-brumadinho-mg-dia-25-01-19/
>
> Atenciosamente
> *[image: cropped-logo_512.png]*
>
> *Narcélio de Sá*
> Mestre em Geografia - UFC
> Analista de Sistema de Informação Geográfica - CAGECE
> Coordenador da comunidade QGIS Brasil 
> www.narceliodesa.com
> [image: Facebook]  
> [image:
> Twitter]  [image: Google Plus]
> 
>  [image: Youtube]  [image:
> Linkedin] 
>
>
> Em sáb, 26 de jan de 2019 às 18:03, Theo A 
> escreveu:
>
>> Caros membros da OSM Brazil,
>>
>>
>>
>> O Humanitarian OpenStreetMap Team está consciente dos acontecimentos nas
>> áreas ao redor da barragem em Brumadinho.
>>
>>
>>
>> Estamos em processo de criação de novas tasks no nosso Tasking Manager
>> para ajudar nos esforços de recuperação. Nosso Tasking Manager, que poderá
>> ser encontrado encontrado através do link https://tasks.hotosm.org/
>> ,
>> dirige os usuários para areas específicas que serão mapeadas no
>> OpenStreetMaps, ajudando assim a coordenar os esforços de recuperação.
>>
>>
>>
>> Caso haja qualquer pergunta, por favor sintam-se à vontade para nos
>> contactar: activat...@hotosm.org ou faça parte da conversa no nosso
>> Slack: http://slack.hotosm.org/
>> 
>> .
>>
>>
>>
>> Obrigado com antecedência por suas contribuições.
>>
>>
>>
>> Cumprimentos,
>>
>> Humanitarian OpenStreetMap Team - Disaster Activation Coordination.
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-us] The San Jose / Santa Clara border

[Andy Townsend]

Thanks to everyone who replied - I've reverted the change in 
https://www.openstreetmap.org/changeset/66672189 .


On 27/01/2019 01:50, Joseph Eisenberg wrote:
Do the latest NGS topographical maps show the city limits properly? 
Those are public domain
On Sun, Jan 27, 2019 at 10:16 AM OSM Volunteer stevea 
mailto:stevea...@softworkers.com>> wrote:


On Jan 26, 2019, at 4:00 AM, Andy Townsend mailto:ajt1...@gmail.com>> wrote:
> A mapper has recently changed this to "cut the corner off" north
of the 880 between San Jose airport and Stevens Creek Mall /
Westfield Valley Fair.  You can see the change at

http://overpass-api.de/achavi/?changeset=66619223=18=37.33883=-121.93327=B0TTTFT
.
>
> Some of this mapper's previous changes have had to be undone, so
I did check the node change made here to see if it might be one of
them.  However, according to the node history

https://www.openstreetmap.org/node/373647840/history#map=13/37.3600/-121.9066
the original source of this node was a changeset quite a while ago
with a description "adjust boundaries based on san jose city map,
bing, and common sense ".  It therefore would be great if a local
could check it if possible.

I'm fairly local (SJC is my "home airport") yet I'm not finding
easily-available San José City Limit boundaries in an
ODbL-compatible format which I could use to relatively quickly
repair the damage.  (The user mk408 has a history of "making it up
as he sees fit" OSM data entry which many have disputed or
redacted, for example, many years ago he made MANY roads in the
entire South Bay region — Campbell, Los Gatos, Monte Sereno,
southern San José —into highway=tertiary roads, and that remained
very questionable until it slowly but surely "healed itself,"
again, this took months-to-years).  There are some geo data at
http://csj-landzoning.appspot.com/index.html which indicate the
present OSM data are "largely correct," the exception being that
the area directly over the northern part of the airport do not
include the "leg" that "covers" runway 12L/30R and that the acute
angle over taxiways V, W and W1 is more like "aligned with these
taxiways, rather than cutting across them."  You really have to
see them rather than expect that I can describe them with text. 
They are, again, "mostly correct" but could use some rather minor
correction.

As I bumped into somebody on a plane on my way back from SOTM-US
Seattle (2016) who works in the San José City Hall and when she
met me was bowled over at the coincidence that I was the very
person sitting next to her drinking gin and tonic who entered into
OSM most of Santa Clara County's bikeways/bicycle infrastructure
and network=lcn routing (which the city office found "extremely
helpful" — her words), it's conceivable that I might be able to
use that to sway release of some data which could be forthcoming. 
While I don't know quite who to call, exactly, if somebody wants
to "release to me" ODbL-compatible data which need to be
harmonized with what are now in OSM, I'll volunteer to be the
"nexus of citizen entry" to assure they find their way into our
wonderful map.  Send me a pointer to the data, assure me they are
ODbL-OK and I'll "merge" these into OSM.

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

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

Re: [Talk-it] Perché si guadagna di più non importando cecamente i dati ufficiali

[Alfredo Gattai]

Ciao,
non faccio parte di una PA ma come Alessandro ho avuto modo di interagire
parecchio, facendo poi parte di un'organo centrale del CAI (che e' un'ente
pubblico), un po' di pratica l'ho fatta.



> La PA ha i propri regolamenti e una certa lentezza, per utilizzare uno
> sfumato eufemismo :-) , nel modificarli.
> Nella maggior parte dei casi il DB Topografico è disgiunto dagli altri
> DB, altrimenti sarebbe facile pensare che le sezioni urbanistiche
> inviino le modifiche in formato digitale e queste vengano inserite per
> aggiornare il DBtopo.
> Le commesse e i relativi centri di costo vengono aperte e chiuse: quando
> si prevede un aggiornamento si stanzia una somma per l'invio dei
> verificatori che viene spesa in X mesi, dopodichè sino al prossimo
> aggiornamento non penso inviino qualcuno in giro.
>
>
Partiamo da questi punti:

- i vari DB sono nati a livello regionale e talvolta comunale e non per
spinta nazionale con linee guida e specifiche per i modelli dei dati
- nonostante la presenza di tecnici qualificati, spesso si e' proceduto con
propri progetti senza guardare cosa c'era di gia' fatto. Questo e' accaduto
anche a causa di personalismo politici piu' che per scarsa capacita' di chi
se ne e' occupato.
- alcuni sono vecchi di decenni, quindi non c'erano neanche a disposizione
le "best practices" moderne
- i progetti di creazione dei vari DB sono stati tutti concepiti senza la
manutenzione e cioe' c'era un budget per creare il DB e popolarlo ma
nessuno prevedeva un budget annuale per il mantenimento "sperando"  poi che
questo o quell'ufficio potesse farlo nelle more di altre attivita'. Questo
e' un errore che nell'industria non si fa piu' ma negli enti e' ancora
frequente in quanto non sapendo quando ti ricapita questo o quel
finanziamento si preferisce intanto mettere su qualcosa e poi si spera
nella provvidenza.

Per fortuna il vento sa cambiando e ci sono regioni che si sono preoccupate
di andare a vedere cosa hanno fatto gli altri ed hanno cercato di usare
modelli dati gia' diffusi. Posso citare l'ultima in ordine di tempo
(Regione Sardegna) che ha usato un modello diffuso gia' usato ed ha
studiato a fondo i manuali CAI per la parte riguardante i percorsi
escursionistici.

Un vero aggiornamento organizzato non accadra' fino a quanto a livello di
governo centrale non ci sara' la spinta ad uniformare i DB se non con lo
stesso modello di dati ma con almeno una interoperabilita' stabilita e
consolidata. Solo a quel punto con opportuni automatismi sara' possibile
implementare una sorta di obbigatorieta' di aggiornamento.

L' IGM sta facendo un lavoro di conflation di tutti i DB regionali per fare
delle carte 1:5, chissa' che non sia l'inizio di qualcosa di buono.

Fino ad allora, come Osmer possiamo e dobbiamo continuare a fare gli
ambasciatori dell'open data e provare a suggerire soluzioni in tal senso.

Ciao
Alfredo




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

Re: [Talk-us] The San Jose / Santa Clara border

[Jack Burke]

Does anyone know someone who lives in the "disputed" area? If so, then one 
definitive information point is what local government elections he/she can vote 
in. 

-jack 
-- 
Typos courtesy of fancy auto spell technology

On January 26, 2019 8:50:39 PM EST, Joseph Eisenberg 
 wrote:
>Do the latest NGS topographical maps show the city limits properly?
>Those
>are public domain
>On Sun, Jan 27, 2019 at 10:16 AM OSM Volunteer stevea <
>stevea...@softworkers.com> wrote:
>
>> On Jan 26, 2019, at 4:00 AM, Andy Townsend  wrote:
>> > A mapper has recently changed this to "cut the corner off" north of
>the
>> 880 between San Jose airport and Stevens Creek Mall / Westfield
>Valley
>> Fair.  You can see the change at
>>
>http://overpass-api.de/achavi/?changeset=66619223=18=37.33883=-121.93327=B0TTTFT
>> .
>> >
>> > Some of this mapper's previous changes have had to be undone, so I
>did
>> check the node change made here to see if it might be one of them.
>> However, according to the node history
>>
>https://www.openstreetmap.org/node/373647840/history#map=13/37.3600/-121.9066
>> the original source of this node was a changeset quite a while ago
>with a
>> description "adjust boundaries based on san jose city map, bing, and
>common
>> sense ".  It therefore would be great if a local could check it if
>possible.
>>
>> I'm fairly local (SJC is my "home airport") yet I'm not finding
>> easily-available San José City Limit boundaries in an ODbL-compatible
>> format which I could use to relatively quickly repair the damage. 
>(The
>> user mk408 has a history of "making it up as he sees fit" OSM data
>entry
>> which many have disputed or redacted, for example, many years ago he
>made
>> MANY roads in the entire South Bay region — Campbell, Los Gatos,
>Monte
>> Sereno, southern San José —into highway=tertiary roads, and that
>remained
>> very questionable until it slowly but surely "healed itself," again,
>this
>> took months-to-years).  There are some geo data at
>> http://csj-landzoning.appspot.com/index.html which indicate the
>present
>> OSM data are "largely correct," the exception being that the area
>directly
>> over the northern part of the airport do not include the "leg" that
>> "covers" runway 12L/30R and that the acute angle over taxiways V, W
>and W1
>> is more like "aligned with these taxiways, rather than cutting across
>> them."  You really have to see them rather than expect that I can
>describe
>> them with text.  They are, again, "mostly correct" but could use some
>> rather minor correction.
>>
>> As I bumped into somebody on a plane on my way back from SOTM-US
>Seattle
>> (2016) who works in the San José City Hall and when she met me was
>bowled
>> over at the coincidence that I was the very person sitting next to
>her
>> drinking gin and tonic who entered into OSM most of Santa Clara
>County's
>> bikeways/bicycle infrastructure and network=lcn routing (which the
>city
>> office found "extremely helpful" — her words), it's conceivable that
>I
>> might be able to use that to sway release of some data which could be
>> forthcoming.  While I don't know quite who to call, exactly, if
>somebody
>> wants to "release to me" ODbL-compatible data which need to be
>harmonized
>> with what are now in OSM, I'll volunteer to be the "nexus of citizen
>entry"
>> to assure they find their way into our wonderful map.  Send me a
>pointer to
>> the data, assure me they are ODbL-OK and I'll "merge" these into OSM.
>>
>> SteveA
>> California
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Terminiamo la traduzione del Tasking Manager 3

[Alessandro Palmas]

Il 27/01/19 10:22, Aury88 ha scritto:

ho finito la traduzione dell'ultima decina di stringhe. purtroppo credo non
mi sia consentito modificare le stringhe di traduzione inserite da altri.
ho notato quelle che credo siano discrepanze su come vengono tradotti alcuni
termini tipo "Task". molto spesso vengono lasciati così altre volte vengono
tradotte; a mio avviso visto che per esempio Task viene scritto con la
lettera iniziale maiuscola consiglio di gestirlo come un nome e lasciarlo in
inglese...lo stesso per "Project".

altro dubbio su AOI  non so se andasse esplicitato o tradotto nella forma
contratta (ADI) o lasciato così com'è.

comunque decidiate di procedere consiglio comunque un controllo qualità che
uniformi le varie stringhe.
my two cents


Grande Aury,
sono in treno e poco fa aprendo Transifex ho visto che mancavano giusto 
due frasi.


Inizialmente avevo tradotto Task come compito, ma poi vedendo che era 
ampiamente usato ho pensato fosse meglio lasciarlo in originale: venerdì 
avevo iniziato a rivederne una parte.
Se chi ha i diritti mi aiuta col review in un paio di giorni finiamo e 
richiedo il push in Github, così potremmo fare un Mapathon a FOSS4G-IT 
col TM interamente tradotto anche in IT


Alessandro

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

Re: [Talk-in] Redesigning the OSM India Logo

[Arun Ganesh]

On Sat, Jan 26, 2019 at 8:23 AM Chetan H A  wrote:

> Hi Arun,
>
> The current logo very good for me. It's the same we are using in @osm_in
> twitter. Thanks to Srividya for creating this.
>
>
Chetan the logo is good, and thanks to Srividya for taking the initiative
to make it.

Brought it up because the flag code of India restricts the use of the
Indian flag in a logo
https://tilakmarg.com/answers/use-of-colour-combination-of-indian-national-flag-in-company-logo/
 .
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] Terminiamo la traduzione del Tasking Manager 3

[Aury88]

ho finito la traduzione dell'ultima decina di stringhe. purtroppo credo non
mi sia consentito modificare le stringhe di traduzione inserite da altri. 
ho notato quelle che credo siano discrepanze su come vengono tradotti alcuni
termini tipo "Task". molto spesso vengono lasciati così altre volte vengono
tradotte; a mio avviso visto che per esempio Task viene scritto con la
lettera iniziale maiuscola consiglio di gestirlo come un nome e lasciarlo in
inglese...lo stesso per "Project".

altro dubbio su AOI  non so se andasse esplicitato o tradotto nella forma
contratta (ADI) o lasciato così com'è.

comunque decidiate di procedere consiglio comunque un controllo qualità che
uniformi le varie stringhe.
my two cents



-
Ciao,
Aury
--
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-lazio] Incontri mensili nel nuovo anno?

[Marcello Pelato via Talk-it-lazio]

 Quindi per il 7 va bene a tutti e due?(Almeno tra quelli che hanno risposto...)
On Friday, January 25, 2019, 7:50:23 PM GMT+1,  
wrote:  
 
 Arghh io lunedì 28 non ci sono, potrei il lunedì dopo!

Sent from my iPhone

> On 25 Jan 2019, at 19:12, Martin Koppenhoefer  wrote:
> 
> per me andrebbe bene il lunedì 28 :)
> 
> Ciao,
> Martin
>   ___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [Talk-it] Perché si guadagna di più non importando cecamente i dati ufficiali

[Alessandro Palmas]

Il 26/01/19 08:34, Aury88 ha scritto:

immagino che il problema della scarsità di risorse sia tutt'oggi attuale di
conseguenza o non fanno verifiche in continuo ma solo in maniera periodica
(ad es. ogni 5 anni) o lo fanno ma non ufficialmente (il singolo addetto che
confronta il dato ufficiale con OSM) oppure hanno trovato altri strumenti
(ad es. mapillary e la sua IA per il riconoscimento degli elementi)
altrimenti e questo è il mio sospetto, questo è un lavoro non più necessario
se hanno predisposto metodologie per migliorare il monitoraggio dei
cambiamenti (ad es. imponendo la comunicazione obbligatoria dell'avvenuto
cambiamento per poter accedere al finanziamento dell'opera) e osm è servito
solamente all'inizio per partire da una condizione aggiornata.



Premesso che come sai non sono dentro la macchina P.A. ma ho parlato 
direttamente con almeno 6 regioni e diversi comuni. La mia visione è 
quindi parziale. Se ci leggesse qualcuno addentro alla questione 
potrebbe correggere e/o integrare questa mia mail.


La PA ha i propri regolamenti e una certa lentezza, per utilizzare uno 
sfumato eufemismo :-) , nel modificarli.
Nella maggior parte dei casi il DB Topografico è disgiunto dagli altri 
DB, altrimenti sarebbe facile pensare che le sezioni urbanistiche 
inviino le modifiche in formato digitale e queste vengano inserite per 
aggiornare il DBtopo.
Le commesse e i relativi centri di costo vengono aperte e chiuse: quando 
si prevede un aggiornamento si stanzia una somma per l'invio dei 
verificatori che viene spesa in X mesi, dopodichè sino al prossimo 
aggiornamento non penso inviino qualcuno in giro.


L'uso di Mapillary per la PA in Italia non penso sia ancora previsto. 
Tempo fa, parlando di verifiche sulla viabilità con una grossa regione 
del centro nord, avevo consigliato loro di sperimentare Mapillary e il 
loro motore di IA per riconoscere i cartelli stradali (vedi recente blog 
su Mapillary riguardo una cittadina negli US) ma non se ne fece nulla.
Nell'esempio che avevo portato, dopo un'ottima partenza foriera di 
ulteriori collaborazioni, la dirigente non ha più ritenuto opportuno 
proseguire i discorsi che erano partiti e ovviamente si è tutto arenato.


La comunicazione obbligatoria potrebbe essere un primo passo ma sarebbe 
l'ennesima legge inattuata perchè c'è l'enorme scoglio 
dell'incompatibilità dei molti DB e formati diversi.


Come OSMer cerco sempre di sperimentare nuove soluzioni mostrando poi 
gli eventuali risultati significativi a meeting o conferenze (come al 
prossimo FOSS4G-IT).


Alessandro

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