date:20190128

Hi Paul,

Once you get out into rural areas, it's sometimes the case that an 
entire hamlet is covered by a one or two postcodes. There may be named 
streets but according to RM/PAF these are ignored and such addresses 
take the form: building name/number, locality, post town, postcode. 
The more natural fit, following the structure prompted in the iD 
editor, for example, would be building name/number, street, locality*, 
postcode.
I've encountered this situation where RM addresses for a village don't 
include the street names, even though the streets have signed names.  My 
view is do include the street names. I've no idea why they are left out, 
because finding addresses in a village where the houses have names 
rather than numbers can be difficult, even when the street is known.

I wouldn't worry about the validator as long as you are reasonably sure 
the data you have added is accurate. These validation tools are very 
useful, but they are only intended to suggest things that might be 
wrong.  Mappers sometimes fall into the trap of tagging for the validator.

Even in villages with established streets and house numbers, there 
will be outlying properties where the street names will be foregone: 
S36 7GG is an example of this.
For outlying properties, I don't think there is any harm in including 
addr:street, regardless of official practice, assuming there is a 
logical street to use. Sometimes remote properties are grouped by a 
sub-locality name, in which case I would use addr:place.

Additionally, it's not clear whether name or addr:housename (or both) 
should be used when mapping anything from a a detached house to a 
building split into multiple addressable units (eg terraces, flats).
I would recommend not duplicating addr:housename and name. Generally 
it's best to avoid putting the same information in more than one address 
tag. For most addresses addr:housename is the best choice and name can 
then be used for things like business names.

Cheers,
Will

On 28/01/2019 22:45, Paul Berry wrote:

Sorry, I only have yet more questions.

Once you get out into rural areas, it's sometimes the case that an 
entire hamlet is covered by a one or two postcodes. There may be named 
streets but according to RM/PAF these are ignored and such addresses 
take the form: building name/number, locality, post town, postcode. 
The more natural fit, following the structure prompted in the iD 
editor, for example, would be building name/number, street, locality*, 
postcode.

*The locality suggested depends on how the area you're working in has 
been mapped. Obviously when mapping you are free to override this.

HD8 8XU & HD8 8XY are a case in point. Do we map to fit the validator 
— in this case, https://osm.mathmos.net/addresses/pc-stats/HD/HD8/8 
which they have fallen foul of — or something else?

Even in villages with established streets and house numbers, there 
will be outlying properties where the street names will be foregone: 
S36 7GG is an example of this.

Additionally, it's not clear whether name or addr:housename (or both) 
should be used when mapping anything from a a detached house to a 
building split into multiple addressable units (eg terraces, flats).

Regards,
/Paul/

On Mon, 28 Jan 2019 at 22:05, Richard Fairhurst > wrote:

I'm not quite sure what you've done with the quoting but you've
attributed me
as writing your reply, which evidently I didn't. :)

Will Phillips wrote:
> I really don't see what is outlandish about using post towns as a
> guide for what goes in the addr:city tag. Royal Mail might be
becoming
> less important, but when most people are asked for their
address, they
> will give their address as defined by Royal Mail.
>
> Looking at the Companies House Registered Companies data for
> Charlbury, I find 235 addresses of which 170 include Chipping
Norton.
> I find Registered Companies data useful because the addresses
appear
> unvalidated and therefore show addresses as people actually
enter them.

No-one in Charlbury describes themselves as living in Chipping Norton.
Honestly, no-one. It's a separate town.

Companies House data for my company shows a registered address of
11 Market
Street, Charlbury, Chipping Norton. That is not because I think I
live in
Chipping Norton. That is because, when you register a company, the
Companies
House autocomplete thing takes your postcode and fills in the
Royal Mail
post-town and other details from PAF.

(TBH, I'm not entirely convinced post towns help Royal Mail in any
case,
given the amount of mail mistakenly delivered to us that is
actually meant
for Mr G--- at 11 Market Street, Chipping Norton...)

Richard

--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

___
Talk-GB mailing

Re: [Talk-pt] Desafio mensal

2019-01-28 Per discussione Marcos Oliveira

Boa iniciativa. :)

Pedro Lima  escreveu no dia segunda, 28/01/2019
à(s) 23:33:

> Conforme falado pelo telegram para dinamizar e coordenar melhor as edições
> feitas pela comunidade, deixo vos o link para quem quiser participar no
> desafio mensal:
> https://tarefas.openstreetmap.pt/project/2 Porto Santo
>
> Cumprimentos,
> Pedro Lima
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

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

Chris, what would you see as a good data model for a UK address in OSM?
Just house number/name, street, postcode? It has been mentioned a couple
of times in this thread that the "addr:" model was intended in the UK to
contain postal addresses, not any other sort of address. Are you
suggesting only storing a subset of the full postal address, and doing a
PAF lookup to get the other fields? 

Apart from the PAF, GeoPlace is the other central repository of address
info which it obtains from LAs and RM. In this document it seems to
indicate that besides the postcode, the Post Town is also assigned by RM
(see page 50): 

https://www.geoplace.co.uk/helpdesk/library/-/asset_publisher/3pCkRTd6bAi9/document/id/335107


On 2019-01-28 23:18, Chris Hill wrote:

> On 28/01/2019 21:56, Colin Smale wrote: 
> 
> On 2019-01-28 22:22, Chris Hill wrote: 
> Post town do not exist, and never have. They are a fiction invented by Royal 
> Mail for their own internal use which they persuaded the public into using 
> for the sole benefit of Royal Mail. 
> ...and for the benefit of anyone posting a letter and expecting it to get 
> delivered properly...
 RM used to use postal towns when post was sorted by hand, but as soon
as mechanised sorting based on postcodes took over postal towns were
just a legacy that no one needed any more. In 1976 I posted a batch of
postcodes from my holiday in Norway. As an experiment I addressed one to
my parents as Number 10, HU14 3BA, UK. It arrived on the same day as all
the others because it had a postcode on it. So post towns were beginning
to be obsolete in 1976.

> In the UK places (as opposed to admin areas) don't have well-defined borders 
> unfortunately. If you live in the "no-mans land" between two villages there 
> is in many cases no way of determining if you are in Village A or Village B.
 Why does a postal town help with this? The postcode is much more
precise than a generalised post town that will cover a wide area - that
was the point of a post town.

>> Addresses are not maintained by RM, local authorities are responsible for 
>> addresses (which obviously don't include postal towns), except for the 
>> postcode. Most LAs have a system to request a new postcode from RM when a 
>> planning application gets approved that will need a new postcode.
> 
> The LA is certainly responsible for house names/numbers and street names. 
> Wouldn't all the rest (not just the post town) be down to RM?
 No the process is that RM only supply the postcode.

>> I don't see what purpose adding post towns to OSM would serve. The ONLY 
>> people who ever used it were Royal Mail as they were the only organisation 
>> to have a sorting office there. I'm sure RM don't need OSM to make 
>> deliveries, so who would we be benefiting by including this? To anyone else 
>> looking for an address the postal town is just confusing.
> 
> Are you saying is that there is no point in adding addresses to OSM? 
> Addresses are also useful for the senders of letters, or users of navigation 
> systems, so I think that might be a little controversial.
 Of course not. Addresses are a fine idea, but real addresses that
actually exist on the ground, not some mythical, out-of-date idea used
by one organisation in the past.

> This document gives loads of examples to aid the interpretation of PAF fields 
> https://www.royalmail.com/sites/default/files/docs/pdf/programmers_guide_edition_7_v5.pdf
 The RM PAF is not the definitive address list for the UK, it is just
the way RM sees it. It is widely used because there is no other
published list of addresses. If we ever see a proper national address
list compiled from the UPRN that local authorities maintain it will not
include any field introduced by a company such as post town. OSM can
help here by not confusing addresses with RM's muddled postal addresses.
 

-- 
cheers
Chris Hill (chillly)

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

Re: [Talk-it] Whodidit non funziona, alternative?

2019-01-28 Per discussione Lorenzo Beltrami

Il giorno lun 28 gen 2019 alle ore 21:20 Marco  ha
scritto:

> Buonasera a tutti, sono ormai 10/15 giorni che Whodidit non funziona più
> a dovere. Nella speranza che possa tornare a funzionare, quali altri
> servizi simili esistono?
>

Ciao Marco,
c'è OSMCha: https://osmcha.mapbox.com/

A mio parere è molto valido, io lo preferisco a Whodidit.
Diciamo che è un po' una fusione tra Whodidit e achavi[1].
Puoi anche farti dei filtri personalizzati e crearti i corrispettivi feed
RSS.

Saluti
Lorenzo

[1] https://overpass-api.de/achavi/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] Hromadná editace/úkol pro všechny? Bylo: Seznam vodních ploch se špatnou kategoriií

2019-01-28 Per discussione Michal Poupa

Ty největší rybníky a přehrady jsem opravil je toho dohně na ty malé
je třeba udělt pomoci robota - ano to landuse=reservoir vzniklo to
nějakým importem.

 Michal

čt 24. 1. 2019 v 14:04 odesílatel majka  napsal:
>
> On Thu, 24 Jan 2019 at 13:18, Pavel Machek  wrote:
>>
>> Ja porad nechapu co presne chcete menit.
>>
>> Co si pamatuju, tak rybnik nema mit natural=*, protoze neni tak uplne
>> prirodni, postavil ho clovek.
>
> To ale (podle wiki) není tak úplně pravda, a naprosto běžně se používá pro i 
> člověkem postavené rybníky a přehrady.
> V landuse je to považované za zastaralé značení, a doporučované je jako 
> natural=water + kombinace.
>
> Wiki je v tomhle zmatečná, každá stránka (i každá jazyková verze) píše něco 
> trochu jiného. Na tom, že je tohle značení považované za zastaralé (i když 
> není výslovně zrušené) se ale shodují všechny.
> Ta debata o zastaralosti probíhala v červnu 2013 - kdy se to znovu “oživilo”, 
> tedy kdy se na wiki revertovalo  deprecated  - a už tenkrát víceméně padla 
> shoda v tom, že samotná “hladina” by měla mít značku water. Z té debaty 
> vyplynula definice landuse=reservoir spíš jako například ochranné pásmo 
> vodního zdroje - tj. ta část “na suchu”, a debatovalo se o tom, jestli/jak 
> tuhle část značit jinak.
>
> Co se dívám na taginfo, řekla bych že většina značení jako landuse=reservoir 
> budou starší importy. Zrovna ten náš dibavod v tom hraje poměrně podstatnou 
> roli.
>
> Majka
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

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

2019-01-28 Per discussione Paul Berry

Sorry, I only have yet more questions.

Once you get out into rural areas, it's sometimes the case that an entire
hamlet is covered by a one or two postcodes. There may be named streets but
according to RM/PAF these are ignored and such addresses take the form:
building name/number, locality, post town, postcode. The more natural fit,
following the structure prompted in the iD editor, for example, would be
building name/number, street, locality*, postcode.

*The locality suggested depends on how the area you're working in has been
mapped. Obviously when mapping you are free to override this.

HD8 8XU & HD8 8XY are a case in point. Do we map to fit the validator — in
this case, https://osm.mathmos.net/addresses/pc-stats/HD/HD8/8 which they
have fallen foul of — or something else?

Even in villages with established streets and house numbers, there will be
outlying properties where the street names will be foregone: S36 7GG is an
example of this.

Additionally, it's not clear whether name or addr:housename (or both)
should be used when mapping anything from a a detached house to a building
split into multiple addressable units (eg terraces, flats).

Regards,
*Paul*

On Mon, 28 Jan 2019 at 22:05, Richard Fairhurst 
wrote:

> I'm not quite sure what you've done with the quoting but you've attributed
> me
> as writing your reply, which evidently I didn't. :)
>
> Will Phillips wrote:
> > I really don't see what is outlandish about using post towns as a
> > guide for what goes in the addr:city tag. Royal Mail might be becoming
> > less important, but when most people are asked for their address, they
> > will give their address as defined by Royal Mail.
> >
> > Looking at the Companies House Registered Companies data for
> > Charlbury, I find 235 addresses of which 170 include Chipping Norton.
> > I find Registered Companies data useful because the addresses appear
> > unvalidated and therefore show addresses as people actually enter them.
>
> No-one in Charlbury describes themselves as living in Chipping Norton.
> Honestly, no-one. It's a separate town.
>
> Companies House data for my company shows a registered address of 11 Market
> Street, Charlbury, Chipping Norton. That is not because I think I live in
> Chipping Norton. That is because, when you register a company, the
> Companies
> House autocomplete thing takes your postcode and fills in the Royal Mail
> post-town and other details from PAF.
>
> (TBH, I'm not entirely convinced post towns help Royal Mail in any case,
> given the amount of mail mistakenly delivered to us that is actually meant
> for Mr G--- at 11 Market Street, Chipping Norton...)
>
> Richard
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html
>
> ___
> 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

2019-01-28 Per discussione Chris Hill



On 28/01/2019 21:56, Colin Smale wrote:


On 2019-01-28 22:22, Chris Hill wrote:

Post town do not exist, and never have. They are a fiction invented 
by Royal Mail for their own internal use which they persuaded the 
public into using for the sole benefit of Royal Mail.
...and for the benefit of anyone posting a letter and expecting it to 
get delivered properly...
RM used to use postal towns when post was sorted by hand, but as soon as 
mechanised sorting based on postcodes took over postal towns were just a 
legacy that no one needed any more. In 1976 I posted a batch of 
postcodes from my holiday in Norway. As an experiment I addressed one to 
my parents as Number 10, HU14 3BA, UK. It arrived on the same day as all 
the others because it had a postcode on it. So post towns were beginning 
to be obsolete in 1976.
In the UK places (as opposed to admin areas) don't have well-defined 
borders unfortunately. If you live in the "no-mans land" between two 
villages there is in many cases no way of determining if you are in 
Village A or Village B.
Why does a postal town help with this? The postcode is much more precise 
than a generalised post town that will cover a wide area - that was the 
point of a post town.
Addresses are not maintained by RM, local authorities are responsible 
for addresses (which obviously don't include postal towns), except 
for the postcode. Most LAs have a system to request a new postcode 
from RM when a planning application gets approved that will need a 
new postcode.
The LA is certainly responsible for house names/numbers and street 
names. Wouldn't all the rest (not just the post town) be down to RM?

No the process is that RM only supply the postcode.
I don't see what purpose adding post towns to OSM would serve. The 
ONLY people who ever used it were Royal Mail as they were the only 
organisation to have a sorting office there. I'm sure RM don't need 
OSM to make deliveries, so who would we be benefiting by including 
this? To anyone else looking for an address the postal town is just 
confusing.
Are you saying is that there is no point in adding addresses to OSM? 
Addresses are also useful for the senders of letters, or users of 
navigation systems, so I think that might be a little controversial.
Of course not. Addresses are a fine idea, but real addresses that 
actually exist on the ground, not some mythical, out-of-date idea used 
by one organisation in the past.


This document gives loads of examples to aid the interpretation of PAF 
fields

https://www.royalmail.com/sites/default/files/docs/pdf/programmers_guide_edition_7_v5.pdf

The RM PAF is not the definitive address list for the UK, it is just the 
way RM sees it. It is widely used because there is no other published 
list of addresses. If we ever see a proper national address list 
compiled from the UPRN that local authorities maintain it will not 
include any field introduced by a company such as post town. OSM can 
help here by not confusing addresses with RM's muddled postal addresses.


--
cheers
Chris Hill (chillly)

___
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

2019-01-28 Per discussione Richard Fairhurst

I'm not quite sure what you've done with the quoting but you've attributed me
as writing your reply, which evidently I didn't. :)

Will Phillips wrote:
> I really don't see what is outlandish about using post towns as a 
> guide for what goes in the addr:city tag. Royal Mail might be becoming 
> less important, but when most people are asked for their address, they 
> will give their address as defined by Royal Mail.
>
> Looking at the Companies House Registered Companies data for 
> Charlbury, I find 235 addresses of which 170 include Chipping Norton. 
> I find Registered Companies data useful because the addresses appear 
> unvalidated and therefore show addresses as people actually enter them.

No-one in Charlbury describes themselves as living in Chipping Norton.
Honestly, no-one. It's a separate town.

Companies House data for my company shows a registered address of 11 Market
Street, Charlbury, Chipping Norton. That is not because I think I live in
Chipping Norton. That is because, when you register a company, the Companies
House autocomplete thing takes your postcode and fills in the Royal Mail
post-town and other details from PAF.

(TBH, I'm not entirely convinced post towns help Royal Mail in any case,
given the amount of mail mistakenly delivered to us that is actually meant
for Mr G--- at 11 Market Street, Chipping Norton...)

Richard

--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

___
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

On 2019-01-28 22:22, Chris Hill wrote:

> Post town do not exist, and never have. They are a fiction invented by Royal 
> Mail for their own internal use which they persuaded the public into using 
> for the sole benefit of Royal Mail.

...and for the benefit of anyone posting a letter and expecting it to
get delivered properly... 

In the UK places (as opposed to admin areas) don't have well-defined
borders unfortunately. If you live in the "no-mans land" between two
villages there is in many cases no way of determining if you are in
Village A or Village B. 

> Addresses are not maintained by RM, local authorities are responsible for 
> addresses (which obviously don't include postal towns), except for the 
> postcode. Most LAs have a system to request a new postcode from RM when a 
> planning application gets approved that will need a new postcode.

The LA is certainly responsible for house names/numbers and street
names. Wouldn't all the rest (not just the post town) be down to RM? 

> I don't see what purpose adding post towns to OSM would serve. The ONLY 
> people who ever used it were Royal Mail as they were the only organisation to 
> have a sorting office there. I'm sure RM don't need OSM to make deliveries, 
> so who would we be benefiting by including this? To anyone else looking for 
> an address the postal town is just confusing.

Are you saying is that there is no point in adding addresses to OSM?
Addresses are also useful for the senders of letters, or users of
navigation systems, so I think that might be a little controversial.

This document gives loads of examples to aid the interpretation of PAF
fields 
https://www.royalmail.com/sites/default/files/docs/pdf/programmers_guide_edition_7_v5.pdf___
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

2019-01-28 Per discussione Mark Goodge




On 28/01/2019 18:50, Lester Caine wrote:

On 28/01/2019 18:24, Will Phillips wrote:


There are certainly occasions when the street name is needed. For 
example, I recently surveyed a single postcode (DE72 2HP) containing 
two houses with the same house name, but different street names.  
Postcodes do sometimes cover two streets in rural areas. In these 
cases one might technically be a subsidiary street, but it's often not 
obvious which one.


One could say that DE72 2HP is breaking Royal Mail's own rules, but it 
is a rare exception to the rule, and often you find the street is 
actually the secondary build reference rather than the street in the raw 
data.


It isn't breaking a rule. The rule is that unit + street + postcode is 
the minimum required for an unambiguous postal address, as far as 
standard postcodes are concerned (large user postcodes are different, of 
course, but they, too, are a minority).


It is often the case that a postcode only covers a single street. But 
that's by no means universal, and it certainly isn't rare that it covers 
more than one.


Bear in mind that the whole point of the postcode system is to 
facilitate the delivery of post by Royal Mail. The final two characters 
of a postcode are the "walk" - literally, the smallest unit of the 
postman's round. And if there happens to be a pair of short streets, or 
a short street off a longer one, then they are often incorporated into 
the same walk. Topologically, this is the most common walk:


 -

but this is a common one, too:

 ---
  |

or this:

 |
 |--
 |

If the "vertical" section has a different name to the horizontal 
section, then it will typically also have duplicate numbering. Which 
means the street name is necessary to disambiguate.


I've just had a look at the Land Registry price paid data for my 
postcode area (WR), and there are 364 postcodes within it that are 
associated with more than one street name. That's a not a trivial or 
ignorable number, by any means, even if it is only a minority of 
postcodes. To guarantee a completely deliverable postal address, you 
need the street name.


Mark

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

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

2019-01-28 Per discussione OSM Volunteer stevea

(Lengthy reply alert)
Hi Minh:

Thanks for your (always thorough and well-researched) pointers and history — 
though I don't recall "impressing LAFCO" upon you, I did mention it in the 
context of admin_level, so, OK, whatever!  Good for Santa Clara LAFCO for 
publishing municipal boundaries into the PD.  I am again thankful we live in a 
state with excellent public data in the PD along with our "sunshine laws."

I like that you made Seven Trees an admin_level=10 for reasons you did, even as 
you've described other SJ neighborhoods as "amorphous" (exactly the right word, 
imo!)  I wouldn't have noticed had you not sent me links [1].

"Urban islands as a LAFCO high priority to streamline" is something I've never 
heard of before.  Notwithstanding the letter LAFCO sent City of San José nearly 
eight years ago [3], I believe it is the City of San José itself which "serves 
as the authority on" its own municipal boundary.  LAFCO might have something to 
say (keeping accurate maps / GIS data, for example) about all cities in Santa 
Clara County, but I don't think anyone contends that LAFCO doesn't define 
municipal boundaries, the cities themselves do.  Indeed, LAFCO's letter says it 
can "encourage" annexations (of islands) and waive its fees (to incentivize a 
"streamlined process" for islands 150 acres or less) but it cannot force a city 
to do so, whether this is a "high priority" for the LAFCO or not.

Using link [4] and blending with the instant topic (which I volunteered to 
remedy), I examined the five pages of City of Santa Clara.  The first four 
(pages 45-48) are "islands" which share a boundary with City of San José (the 
fifth is an island solely inside of the City of Santa Clara).  None of these 
involve the area around the airport / Westfield Valley Fair, which was Andy 
Townsend's "area of concern," prompting me to answer that I'd take a look.  
(SC05, page 48, is pretty close, but is north of the airport and involves a 
creek edge near Trimble and Orchard).  Those four "islands" probably could be 
used to (rather crudely) "hand draw modify" the Santa Clara City Limit boundary 
in OSM (relation 2221647) but it isn't clear to me how what these maps define 
as Urban Service Boundary is or isn't the actual city limit boundary for Santa 
Clara.  As I think about it, the identification of these four islands (the 
fifth might become an "inner" member of that relation) in this document COULD 
be used to exclude these islands from the City Limit, but I'm not sure that is 
accurate (it likely is, I'm simply not sure).  So while these resources might 
qualify as "interesting," I don't find them wholly relevant to what I 
volunteered to do "near the airport."

However, links [5] and especially [6] yield dense, recent, tasty data.  Having 
used ArcGIS layers before like this (largely while mapping to fix TIGER rail), 
I can set a basemap of OSM while viewing these data.  Doing so allows me to 
find where there are some relatively minor differences, so I elected to fix 
these, "manually" using JOSM.

These (minor) changes were along the "grass edge" NW of the 101-Trimble 
interchange, westerly to the UP Coast Subdivision rail bridge crossing 101, 
southerly to just north of Central Expressway (not south, a significant change 
making OSM's representation of CE W of Trimble/De La Cruz to the rail bridge 
now in Santa Clara, not San José).  This continues easterly across Trimble into 
the airport, as far as Taxiway Y, includes better-traced (though likely not 
perfectly accurate) rectangular and triangular areas of northern portions of 
runways and taxiways, south along De La Cruz and excludes Memorial Cross Park 
(in San José, not Santa Clara).  The barrier=fence had to be node-by-node 
unglued from the city limit (but kept glued to the parking lot) to be better 
characterized as "along Martin Avenue" (and so was), SE on Martin Avenue (with 
some "jogs") to a bit further SE on Aviation Avenue, southerly (with "jogs") to 
Campbell Avenue near Stephen Schott Stadium.

From there, the boundary needed to be moved easterly by about 10 meters, so it 
was, past Sherwood and along Portola Avenue.  Adjustments were made to better 
align with The Alameda, past Morse and Idaho and to I-880, where a 90-degree 
westerly boundary continues to Newhall and Monroe, where as it follows the 
southern boundary of Santa Clara Mission Cemetery, it is correct (enough for 
now).

The ways I changed have IDs 166659029 and 97341711 (recently reverted by Andy 
Townsend), part of the Santa Clara (city) municipal boundary relation.  I 
believe this is moderately better, which is "moderately better."

SteveA

> From: Minh Nguyen 
> Subject: Re: [Talk-us] The San Jose / Santa Clara border
> Date: January 28, 2019 at 5:06:15 AM PST
> To: talk-us@openstreetmap.org
> 
> 
> On 2019-01-26 17:13, OSM Volunteer stevea wrote:
>> While I don't know quite who to call, exactly, if somebody wants to "release 
>> to me" ODbL-compatible data which need

[Talk-it] Whodidit non funziona, alternative?

2019-01-28 Per discussione Marco

Buonasera a tutti, sono ormai 10/15 giorni che Whodidit non funziona più 
a dovere. Nella speranza che possa tornare a funzionare, quali altri 
servizi simili esistono?


Grazie

Marco


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

[OSM-talk-be] Next OSM Arlon meetup 4th February / Prochaine réunion OSM Arlon 4 février

2019-01-28 Per discussione Julien Minet

Hello!/Bonjour!

The next OpenStreetMap Arlon meetup is scheduled on Monday 4th of February,
19h30. Everyone welcome, from the perfect beginner to the experienced
mapper!  All infos and subscription here:
https://www.meetup.com/OpenStreetMap-Belgium/events/257183572/

La prochaine rencontre des contributeurs d'OpenStreetMap d'Arlon et
d'ailleurs aura lieu le lundi 22 octobre à 19h30. Tout le monde intéressé
par OSM est le bienvenu, du parfait débutant au cartographe expérimenté.
N'hésitez pas à venir si vous êtes juste intrigué par le projet
OpenStreetMap et la cartographie participative. Toutes les infos et
inscription sur
https://www.meetup.com/OpenStreetMap-Belgium/events/257183572. Nous nous
rencontrerons au Tennis Club Garissart à Weyler.

Happy mapping/Bonne carto

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

Re: [Talk-at] EGU mapathon Wien - help needed :)

2019-01-28 Per discussione Andreas

Hi Faith,

Stefan asked for the topic of the mapathon and not what it is. There
were few mapathons in Austria in the past.

I only attended one which was organized by the Red Cross organisation
and we had to map some place at Ethiopia for a water ressource project.

Kind regards
Andreas as Geologist

Am 28.01.19 um 10:02 schrieb Faith Taylor:
> Hi Stefan,
> 
> Thanks for your interest. A mapathon is a mapping party ('mapping
> marathon'). These are quite popular in
> London: https://www.youtube.com/watch?v=pAcsCmvG2hs 
> 
> A group gets together to work on mapping an area through the HOT Tasking
> Manager, and usually pizza is served :) 
> 
> If these don't already, it would be great if these were a regular event
> in Austria. They are a good way to meet other people interested in GIS
> and OSM.
> 
> Best wishes,
> 
> Faith 
> 
> On Fri, 25 Jan 2019 at 17:28, Stefan Tauner  > wrote:
> 
> On Wed, 23 Jan 2019 16:34:32 +
> Faith Taylor  > wrote:
> 
> > Hello OSM Austria,
> >
> > Myself and four colleagues are planning a mapathon at the European
> > Geosciences Union General Assembly in Vienna the week of the
> 8th-12th April
> > (exact date TBC).
> >
> > It would be wonderful if some of the OSM Austria team are able to
> help us
> > in this activity.
> >
> > Over 10,000 earth scientists attend the conference (although the
> number at
> > the mapathon will be less - maybe 100 - 200!). Some of them like
> us will be
> > experienced mappers, others will be quite new to this. We are very
> excited
> > that this is the first time a mapathon has taken place at the
> conference.
> 
> Hi Faith,
> 
> I probably won't attend or help out but I was still wondering if the
> mapathon has some kind of topic already or if it is more like a general
> OSM (introdcution) workshop. Knowing the general direction of the event
> might spark more interesting ;)
> 
> -- 
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
> 
> 
> 
> -- 
> Dr Faith Taylor
> 
> Lecturer in Geographic Information Science 
> University of Portsmouth
> 
> faith.tay...@port.ac.uk 
> +44 (0)23 9284 2477
> @faithatron  
> 
> Recent papers: 
> Dodman, D., Adelekan, I., Brown, D., Leck, H., Manda, M., Mberu, M.,
> Pelling, M., Rusca, M., Satterthwaite, D., Taylor, FE (2018) 'A Spectrum
> of Methods for a Spectrum of Risk: Generating Evidence to Understand and
> Reduce Urban Risk in Sub-Saharan Africa'
> /Area/, https://doi.org/10./area.12510 
> 
> Taylor, FE, Malamud, BD, Witt, A., Guzzetti, F. (2018) 'Landslide
> Ellipticity, Shape and Length to Width Ratio' /Earth Surface Processes
> and Landforms/. Free read-only version available
> here: https://rdcu.be/9BHa
> 
>  
> 
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 




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

Re: [Talk-it] marciapiedi e strisce pedonali

Io da quando avevo scoperto che iD aveva "inquinato" tutto con
crossing=zebra (per esempio
https://www.openstreetmap.org/user/dieterdreist/diary/42243 ) ho deciso di
utilizzare anch'io crossing=zebra invece di "uncontrolled", il quale non mi
è mai piaciuto molto (le strisce e in generale la segnaletica orizzontale
sono una forma di "controllo", non è uncontrolled).

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

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


On 28/01/2019 15:06, Richard Fairhurst wrote:
I really don't see what is outlandish about using post towns as a 
guide for what goes in the addr:city tag. Royal Mail might be becoming 
less important, but when most people are asked for their address, they 
will give their address as defined by Royal Mail. In cases where local 
people feel this is wrong, then by all means don't use the post town 
or use addr:posttown instead.


Looking at the Companies House Registered Companies data for 
Charlbury, I find 235 addresses of which 170 include Chipping Norton. 
I find Registered Companies data useful because the addresses appear 
unvalidated and therefore show addresses as people actually enter them.


I don't see what is outlandish about using post towns as a guide for 
what goes in the addr:city tag. Royal Mail might be becoming less 
important, but when most people are asked for their address, they will 
still give it as defined by Royal Mail. In cases where local people feel 
this is wrong, then by all means don't use the post town or use 
addr:posttown instead.


Looking at the Companies House Registered Companies data for Charlbury, 
I find 235 addresses of which 170 include Chipping Norton. I find 
Registered Companies data useful because the addresses appear 
unvalidated and therefore show addresses as people actually enter them.


Cheers,
Will

On 28/01/2019 15:06, Richard Fairhurst wrote:

Colin Smale wrote:

As you will know RM have their own particular ideas of the
geography of the UK, all done for their own convenience. It
would certainly avoid some confusion if we used addr:posttown
instead of addr:city.

Fully agree.

I really don't see what is outlandish about using post towns as a 
guide for what goes in the addr:city tag. Royal Mail might be 
becoming less important, but when most people are asked for their 
address, they will give their address as defined by Royal Mail. In 
cases where local people feel this is wrong, then by all means don't 
use the post town or use addr:posttown instead. Looking at the 
Companies House Registered Companies data for Charlbury, I find 235 
addresses of which 170 include Chipping Norton. I find Registered 
Companies data useful because the addresses appear unvalidated and 
therefore show addresses as people actually enter them.



Richard

[1] https://www.bbc.co.uk/news/business-34514024



--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

___
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

2019-01-28 Per discussione Lester Caine


On 28/01/2019 18:24, Will Phillips wrote:

On 28/01/2019 17:28, Lester Caine wrote:
The reality is that for the UK ALL we need is the Postcode to supply a 
reference to the Royal Mail 'postal address' as that is purely a Royal 
Mail invention anyway.  I personally don't see the need to add 
'addr:street' everywhere but that is what people seem to prefer. 
Adding several more addr: fields to EVERY building is just taking 
things too far? 


There are certainly occasions when the street name is needed. For 
example, I recently surveyed a single postcode (DE72 2HP) containing two 
houses with the same house name, but different street names.  Postcodes 
do sometimes cover two streets in rural areas. In these cases one might 
technically be a subsidiary street, but it's often not obvious which one.


One could say that DE72 2HP is breaking Royal Mail's own rules, but it 
is a rare exception to the rule, and often you find the street is 
actually the secondary build reference rather than the street in the raw 
data.


More generally, if we only included the postcode surely there would 
often be no way to discover the correct street without referring to 
closed proprietary data, and a key motivation for adding addresses to 
OSM is to avoid that.


I'm still of a camp that prefers a proper relational dataset rather than 
'flat file'. There is no reason we can't have tables of open source data 
that we reference and a single copy of the details.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione Gabriele Sani

Io dove li ho creati ho seguito le linee guida della wiki

https://www.openstreetmap.org/node/6132935657

Il giorno lun 28 gen 2019 alle ore 19:36 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> Am Mo., 28. Jan. 2019 um 18:41 Uhr schrieb Volker Schmidt <
> vosc...@gmail.com>:
>
>> crossing_ref è pensato solo per il Regno Unito
>>
>
>
> qualcuno lo pensa così, per me è assurdo creare un tag "generico" e
> limitare l'uso su un solo territorio nazionale. Se guardi la mappa è usato
> d'ovunque
> https://taginfo.openstreetmap.org/keys/crossing_ref#map
>
> Ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Building Import update

2019-01-28 Per discussione Yaro Shkvorets

Hey Nate,
I've also looked into it and came across this paper:
https://www.josis.org/index.php/josis/article/view/276/166
Sounds like what we need.
IMO this is the kind of stuff that needs to be dealt with in JOSM on a
per-square basis rather than modifying original data. So you have control
over the result and can possibly tweak it in the process if there are any
issues. I've looked into plugins and found only "Building Generalization"
plugin (
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Building_Generalization)
that is supposed to be able to fix this kind of problem. However, after
running it on an area from Texas import with 90% of problematic buildings,
it turns out to be doing pretty bad job: https://i.imgur.com/P5mbjRf.jpg




On Mon, Jan 28, 2019 at 10:08 AM Nate Wessel  wrote:

> Hi all,
>
> I was reading about orthogonalization yesterday and came across this
> paper...
>
>
> https://icaci.org/files/documents/ICC_proceedings/ICC2009/html/refer/19_2.pdf
>
> ...which describes an algorithm that seems to quite effectively disregard
> angles that are not close to orthogonal while straightening those that are.
> I added a link to it in the wiki. This may not be implemented in JOSM, but
> there's no reason we couldn't pre-process the data in this way.
>
> From Pierre's analysis, it sounds to me like we really do need to consider
> orthogonalizing buildings where possible, which should be pretty much all
> buildings (I could see some buildings sharing nodes getting complicated).
> Once the angles are corrected, I imagine we should be able to simplify with
> a very small threshold and get good results.
>
> Given the number of buildings in this import, this is absolutely something
> worth doing. Four million buildings times one tiny problem equals one
> really huge problem. Let's fix it now while it's still relatively easy.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/28/19 9:17 AM, john whelan wrote:
>
> Interesting, although I'm not sure what the best approach is.
>
> 31 Hamilton is interesting.  If you look at the buildings next to it they
> don't have house numbers.  Look at the history and you'll see it was first
> created in 2010 with potlatch and edited once more in 2011.
>
> At my first glance at Kingston the small deviations form 90 degrees did
> not stand out.
>
> I think we can reasonably expect Microsoft to create a Canadian buildings
> file and you seem to be comfortable that the ones it has in the US are of a
> reasonable standard.
>
> Part of my background is large databases and my personal view is the
> minimum data needed the faster the system runs and less data needs to get
> flipped round and backed up.
>
> Could you run the analysis over Ottawa?
>
> Looking closely at a few in Ottawa I note that there are some bay windows
> and other small features I might not have bothered with if mapping with
> JOSM with the buildings_tool. Because of a few 45 degree angles involved
> this isn't something that can be easily solved.
>
> Ottawa I think at some level can be considered a reasonable success.
> Certainly we added a lot of extra information to the building outlines.
>
> I think the trade off is using the municipal data gives us the buildings
> with perhaps more detail than I might like but many would like to see the
> buildings imported.
>
> Dunno (Do not know for translate tools.)
>
> What is the ideal building outline in OpenStreetMap?
>
> What is an acceptable building outline in OpenStreetMap?
>
> Suggestions
>
> Thanks
>
> Cheerio John
>
> On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:
>
>> 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

Re: [Talk-at] EGU mapathon Wien - help needed :)

2019-01-28 Per discussione Faith Taylor

Hi Stefan,

Thanks for your interest. A mapathon is a mapping party ('mapping
marathon'). These are quite popular in London:
https://www.youtube.com/watch?v=pAcsCmvG2hs

A group gets together to work on mapping an area through the HOT Tasking
Manager, and usually pizza is served :)

If these don't already, it would be great if these were a regular event in
Austria. They are a good way to meet other people interested in GIS and OSM.

Best wishes,

Faith

On Fri, 25 Jan 2019 at 17:28, Stefan Tauner  wrote:

> On Wed, 23 Jan 2019 16:34:32 +
> Faith Taylor  wrote:
>
> > Hello OSM Austria,
> >
> > Myself and four colleagues are planning a mapathon at the European
> > Geosciences Union General Assembly in Vienna the week of the 8th-12th
> April
> > (exact date TBC).
> >
> > It would be wonderful if some of the OSM Austria team are able to help us
> > in this activity.
> >
> > Over 10,000 earth scientists attend the conference (although the number
> at
> > the mapathon will be less - maybe 100 - 200!). Some of them like us will
> be
> > experienced mappers, others will be quite new to this. We are very
> excited
> > that this is the first time a mapathon has taken place at the conference.
>
> Hi Faith,
>
> I probably won't attend or help out but I was still wondering if the
> mapathon has some kind of topic already or if it is more like a general
> OSM (introdcution) workshop. Knowing the general direction of the event
> might spark more interesting ;)
>
> --
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>


-- 
Dr Faith Taylor

Lecturer in Geographic Information Science
University of Portsmouth

faith.tay...@port.ac.uk
+44 (0)23 9284 2477
@faithatron  

Recent papers:
Dodman, D., Adelekan, I., Brown, D., Leck, H., Manda, M., Mberu, M.,
Pelling, M., Rusca, M., Satterthwaite, D., Taylor, FE (2018) 'A Spectrum of
Methods for a Spectrum of Risk: Generating Evidence to Understand and
Reduce Urban Risk in Sub-Saharan Africa' *Area*,
https://doi.org/10./area.12510

Taylor, FE, Malamud, BD, Witt, A., Guzzetti, F. (2018) 'Landslide
Ellipticity, Shape and Length to Width Ratio' *Earth Surface Processes and
Landforms*. Free read-only version available here: https://rdcu.be/9BHa

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

Re: [Talk-it] marciapiedi e strisce pedonali

Am Mo., 28. Jan. 2019 um 18:41 Uhr schrieb Volker Schmidt :

> crossing_ref è pensato solo per il Regno Unito
>


qualcuno lo pensa così, per me è assurdo creare un tag "generico" e
limitare l'uso su un solo territorio nazionale. Se guardi la mappa è usato
d'ovunque
https://taginfo.openstreetmap.org/keys/crossing_ref#map

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

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione arcanma

Volker, 
guardando la pagina wiki sembra che non sia più così, quella in inglese dice
che inizialmente era documentato solo come utilizzato nel Regno Unito, ma
con l'adozione dell'editor iD il suo uso si è diffuso ovunque.
Stando alla descrizione e vedendo l'immagine riportata mi sembra il nostro
classico passaggio pedonale non controllato da semaforo, pensi sia errato
mettere crossing_ref=zebra?

Ciao
Marcello

crossing_ref è pensato solo per il Regno Unito

On Mon, 28 Jan 2019, 18:12 Simone Saviolo simone.saviolo@ wrote:

 Ho un po' di casi simile a quello che descrivi qui:
> https://www.openstreetmap.org/#map=19/45.31836/8.42792
>
> I marciapiedi sono correttamente highway=footway, footway=sidewalk, mentre
> l'attraversamento diventa highway=footway, footway=crossing. Io metto le
> informazioni aggiuntive (soprattutto crossing_ref=zebra|toucan|...,
> supervised=* e lit=*) sul nodo in cui le way dell'attraversamento e della
> strada si incrociano.
>
> Ciao,
>
> Simone

--
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] marciapiedi e strisce pedonali

Am Mo., 28. Jan. 2019 um 18:02 Uhr schrieb Volker Schmidt :

> Finora l'uso più frequente è:
> highway=crossing
> crossing=uncontrolled|traffic_signal|island|unmarked
> supervised=no|yes|(orario)default: "no"
> crossing_ref (solo UK)
> tactile_paving=yes|no!incorrect  (per non vedenti) ancora poco utilizzato
> bicyle=no|yes
> foot=no|yesdefault "yes"
> horse=no|yes default non definito,prsumo che sia "no"
> in combinazione con crossing=traffic_signals possono esser messe
> button_operated=no|yes
> sound_signals:sound=no|yes
>


questo per il nodo, non per il way. E' usato quasi 3 milioni di volte su un
nodo, ma solo 400 volte su un way.
https://taginfo.openstreetmap.org/tags/highway=crossing





> Il problema con la doppia taggatura del del nodo e del highway che
> attraversa è che è possibile taggare in modo contraddittorio, per esempio
> sul way:
> highway=footway
> footway=crossing
> e sul nodo
> highway=crossing
> foot=no
>


no, il problema in generale con foot=no sul nodo dell'incrocio è che vieti
questo punto della strada per pedoni. Immagina una situazione con mappato
solo i cycleway, mentre i marciapiedi sono impliciti. Se quindi crei un
attraversamento dei solo bici con foot=no su un highway=crossing node, il
risultato è che nemmeno lungo la strada possono camminare, non solo non
possono attraversare.

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

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


On 28/01/2019 17:28, Lester Caine wrote:
The reality is that for the UK ALL we need is the Postcode to supply a 
reference to the Royal Mail 'postal address' as that is purely a Royal 
Mail invention anyway.  I personally don't see the need to add 
'addr:street' everywhere but that is what people seem to prefer. 
Adding several more addr: fields to EVERY building is just taking 
things too far? 


There are certainly occasions when the street name is needed. For 
example, I recently surveyed a single postcode (DE72 2HP) containing two 
houses with the same house name, but different street names.  Postcodes 
do sometimes cover two streets in rural areas. In these cases one might 
technically be a subsidiary street, but it's often not obvious which one.


More generally, if we only included the postcode surely there would 
often be no way to discover the correct street without referring to 
closed proprietary data, and a key motivation for adding addresses to 
OSM is to avoid that.



___
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

On 2019-01-28 18:32, Andrzej wrote:

> Hi Will,
> 
> These are very good examples, I wasn't aware of such places. They would 
> indeed best fit addr:locality. How about using addr:locality together with 
> addr:town/suburb/village/hamlet then? Having multiple well defined tags is 
> good - they add useful information. We are not designing an internal PAF 
> database for RM - OSM is supposed to be used for many different purposes, 
> some of which we can't even predict. From this point of view, the richer and 
> the more precise the language the better.

In the UK, the concept of an address is driven by the postal system.
Everybody knows their address, whether they agree with it or not, and
everybody understands that its function is to allow RM (and therefore
everybody with a route planner) to find the right letterbox.

> I want to clarify what I meant by "almost offensive". We are asking people to 
> tag their towns with names of towns they don't relate to, and to add insult 
> to injury we want them to tag their own towns as "localities". At best people 
> will ignore this scheme, at worst they will get very upset. In my discussions 
> about this topic people felt very strongly about their home towns.

Why do you say people don't relate to their address? The addr prefix
makes it very clear that the OSM data refers to an address. Everyone
knows their address. I agree that the use of the word "locality" in this
concept may surprise some, as it is RM terminology. But that's what
happens in data modelling - you have to find a label somehow. The
concept (of a named fuzzy area smaller than a town) exists in UK
addresses, whatever you choose to call it. If we are aiming to find a
way to represent it in OSM, then we have to make a choice as to how to
label it. It is NOT a "village" or a "suburb", even when its name may
suggest that.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-ca] Building Import update

2019-01-28 Per discussione Pierre Béland via Talk-ca

Ok John,
je vais lancer le script pour Ottawa. Mais je dois régler petit soucis 
d'instabilité  windows avec java et osmosis.  Ne peut mettre a jour java. Et 
powershell refuse parfois de reconnaitre commandes exe.

Parmi tous les scripts de conversion de raster / vectoriel, il serait oui 
intéressant de trouver un script opensource qui corrige les problèmes 
d'orthogonalisation. 

Un défi supplémentaire, lorsque des batiments adjacents partagent des lignes de 
contour. Dans JOSM, lorsque je vois de telles situations, je traite si possible 
en bloc tous les batiments et réoriente ensuite si nécessaire pour mieux 
correspondre à l'imagerie.

 
Pierre 
 

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John
On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

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

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione Volker Schmidt

crossing_ref è pensato solo per il Regno Unito

On Mon, 28 Jan 2019, 18:12 Simone Saviolo  Ho un po' di casi simile a quello che descrivi qui:
> https://www.openstreetmap.org/#map=19/45.31836/8.42792
>
> I marciapiedi sono correttamente highway=footway, footway=sidewalk, mentre
> l'attraversamento diventa highway=footway, footway=crossing. Io metto le
> informazioni aggiuntive (soprattutto crossing_ref=zebra|toucan|...,
> supervised=* e lit=*) sul nodo in cui le way dell'attraversamento e della
> strada si incrociano.
>
> Ciao,
>
> Simone
>
> Il giorno lun 28 gen 2019 alle ore 16:30 demon_box <
> e.rossini7...@gmail.com> ha scritto:
>
>> se ho un tratto di marciapiede a sinistra e a destra di una strada
>>
>> highway=footway + footway=sidewalk
>>
>> che poi ad un certo punto "incrociano" un attraversamento pedonale
>> (highway=crossing) che permette di passare da un lato all'altro della
>> strada
>> nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi con
>> una highway=footway oppure cosa?
>>
>> esempio https://www.openstreetmap.org/#map=19/45.55626/10.21816
>> il punto in questione è esattamente al centro
>>
>> ho trovato anche qualcuno che traccia questo collegamento tra i 2
>> marciapiedi e lo tagga per intero highway=crossing ma mi pare proprio che
>> il
>> wiki dica che highway=crossing si utilizza solo su un nodo e non anche su
>> una way.
>>
>> cosa ne pensate?
>>
>> grazie
>>
>> --enrico
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

2019-01-28 Per discussione Andrzej

Hi Will,

These are very good examples, I wasn't aware of such places. They would indeed 
best fit addr:locality. How about using addr:locality together with 
addr:town/suburb/village/hamlet then? Having multiple well defined tags is good 
- they add useful information. We are not designing an internal PAF database 
for RM - OSM is supposed to be used for many different purposes, some of which 
we can't even predict. From this point of view, the richer and the more precise 
the language the better. 

I want to clarify what I meant by "almost offensive". We are asking people to 
tag their towns with names of towns they don't relate to, and to add insult to 
injury we want them to tag their own towns as "localities". At best people will 
ignore this scheme, at worst they will get very upset. In my discussions about 
this topic people felt very strongly about their home towns. 

Best regards, 
Andrzej 



On 29 January 2019 00:08:11 GMT+08:00, Will Phillips  wrote:
>
>> Having said that, I still don't understand the objections to
>addr:town 
>> and addr:village. Can anyone come up with an example of an address 
>> where they wouldn't work? I normally don't care about names but 
>> locality sounds almost offensive. 
>To me 'locality' just sounds neutral. I don't particularly object to 
>addr:town and addr:village, but it does mean we end up with at least 
>three tags rather than one, because in cities suburbs often don't fit 
>easily into those tags, hence the use of addr:suburb.
>
>> Business parks and other campuses are not localities - their names
>are 
>> written before street names, not after them.
>In my experience this often isn't true, perhaps look at more examples. 
>It is relatively common for business park and industrial estate names
>to 
>appear after street names.
>
>Examples:
>Lenton Lane Industrial Estate, Nottingham
>http://osm-nottingham.org.uk/?z=16=-1.17632=52.93295=OSM,1,15=%22Lenton%20Lane%20Industrial%20Estate%22=SearchOpendataJson=1
>
>Trent Lane Industrial Estate, Castle Donington
>http://osm-nottingham.org.uk/?z=16=-1.34152=52.85018=OSM,1,15=%22Trent%20Lane%20Industrial%20Estate%22=SearchOpendataJson=1
>
>Sherwood [Business] Park, Annesley,
>http://osm-nottingham.org.uk/?z=16=-1.25353=53.07037=OSM,1,15=%22Sherwood%20Park%22=SearchOpendataJson=1
>
>Regards,
>Will
>
>
>
>On 28/01/2019 15:06, Andrzej wrote:
>> Is it possible to use addr:locality for both towns and villages? That
>
>> could simplify things quite a bit and I have yet to see an address 
>> that needs a post town and two levels of localities below.
>>
>> Having said that, I still don't understand the objections to
>addr:town 
>> and addr:village. Can anyone come up with an example of an address 
>> where they wouldn't work? I normally don't care about names but 
>> locality sounds almost offensive.
>>
>> Business parks and other campuses are not localities - their names
>are 
>> written before street names, not after them. They're IMO what RM
>calls 
>> "dependent thoroughfares". For these I would simply use addr:place, 
>> which can already be combined with addr:housename and 
>> addr:housenumber. Alternatively we could make a new tag like
>addr:campus.
>>
>> Best regards,
>> Andrzej
>>
>>
>> On 28 January 2019 20:36:24 GMT+08:00, Colin Smale 
>>  wrote:
>>
>> Hi Will,
>>
>> On 2019-01-28 13:19, Will Phillips wrote:
>>
>>> Hi,
>>>
>>> I agree we need another tag below addr:city for localities. For
>>> this I have usually used addr:suburb when mapping in urban areas
>>> and addr:locality elsewhere. Ideally I think it would be best to
>>> have just one recommended tag, perhaps addr:locality, because
>>> having addr:town addr:village and addr:suburb seems too
>>> complicated. Eventually it would be good if editing software, in
>>> particular iD, could provide an extra field to enter the
>>> locality, and it would perhaps be easier for that to happen if
>>> there was only one tag. New mappers often seem to have
>difficulty
>>> entering addresses to the form that they wish and I think the
>>> lack of a locality field is part of the reason.
>>>
>>> For what Royal Mail calls 'Double Dependent Localities' using
>>> addr:sublocality is a possibility, although I wonder whether
>just
>>> sticking with addr:village for this less common situation would
>>> be easier. It depends a bit on whether this tag is only likely
>to
>>> be used for villages and hamlets, or whether it might be useful
>>> in other cases. For example, sometimes names of industrial
>>> estates appear in addresses in a similar way to sublocalities.
>> I don't see any advantage in "addr:village" and
>"addr:suburb" just
>> because they sound familiar or are existing tags. What we are
>> discussing here is a UK-specific solution. The (Double) Dependent
>> Localities may or may not correspond to what people perceive as a
>> "village" or "suburb". In the quoted example,

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

2019-01-28 Per discussione Lester Caine


On 28/01/2019 15:31, Tom Hughes wrote:
The notion that I should tag addresses in Charlbury with 
"addr:city=Chipping
Norton", a town 6 miles away, just because one private delivery 
operator[1]

uses Chipping Norton as an optional part of their addressing is... one of
the more outlandish ideas I've heard in OSM tagging circles, and that's
saying a lot.


To be fair "addr:city=Chipping Norton" would be outlandish even for
an address *in* Chipping Norton...


'city' has always been the wrong title for the field across every 
system, but it is consistent and as far as I am concerned it is the name 
of the primary location, be it 'Birmingham', 'Chipping Norton' or 
'Saintbury'. It does away with the need to make any decision on the 
'size' of the place. That additional places can be added to location to 
more accurately identify it depends on the application, so addr: may 
consist of a lot more elements than we currently cater for anyway.


The reality is that for the UK ALL we need is the Postcode to supply a 
reference to the Royal Mail 'postal address' as that is purely a Royal 
Mail invention anyway.  I personally don't see the need to add 
'addr:street' everywhere but that is what people seem to prefer. Adding 
several more addr: fields to EVERY building is just taking things too far?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione Nick Bolten

I'd like to second this! Also, hi Melanie!

In case it adds useful context, I'd like to give my own recommendations:
(1) get practice in mapping sidewalks yourself and (2) create an IP,
metadata, work, verification, and upkeep plan for the import.

For (1), the goal is to become familiar with the complexities and pitfalls
of mapping the information you want, as it's not actually only sidewalks,
but also intersections, curb ramps, etc, and these are often inconsistent
block-to-block and not well-captured by public data. Many folks have
trouble seeing the need for certain styles of pedestrian mapping until you
give them the task of mapping a neighborhood's sidewalks, curb ramps,
crosswalks, etc, such that routing software could route a wheelchair user
(and everyone else) accurately. Example: in my neighborhood, a very busy
intersection has some curb ramps that are quite a bit 'upstream' of the
intersection, which means I had to map two separate paths: the
directly-across-the-street path for most pedestrians and the
use-the-curb-ramp path for others.

For (2), I'll split it into sections:

a) You'll want to get familiar with the import standards docs:
https://wiki.openstreetmap.org/wiki/Import/Guidelines. The first thing to
figure out is the IP situation, since that can prevent the import entirely.
Is your data public domain / otherwise compatible with OSM's license? If
not, you'll want to get the process of requesting a relicensing ASAP.

b) In my experience, it is often faster to draw from aerial imagery
(particularly the new Mapbox Satellite imagery) + Bing Streetside in JOSM
than it is to import sidewalks due to the number of adjustments that need
to be made. However, if you're bringing in valuable metadata with the
sidewalks and/or crosswalks, that would shift the balance. For example, if
you have high-quality surface data (concrete, asphalt, etc) or a
relationship with agencies such that you could add a dataset ID for
maintenance purposes, that would make all the difference. Is there any
'extra', useful data you could bring in as part of an import?

c) You'll want a work plan: how will the import happen? Using the OSM
Tasking Manager has worked pretty well for us in the past and I believe you
should be able to use the OSM US one (I can help if you don't have
privileges). The primary issue there is to identify your work units (a
single block? Intersections?), because you should ideally map sidewalks and
intersections simultaneously, as the intersections will connect your work
in progress to the rest of the network. If you have the resources, I've
really wanted to add some dependency functionality to the tasking manager
to manage an 'associated intersections first then sidewalks' mapping
strategy. Maybe we could collaborate.

d) Verification is an important step and you'll get it nearly for free if
you use the tasking manager, especially if you work with your local OSM
groups to have some expertise doing reviews. Just keep it in mind.

e) Having a plan for upkeep can save you a lot of time later on. It could
mean engaging with or organizing local OSM communities, having a plan for
structured OSM contributions in your implementation of AccessMap, or a
strategy for triggering suggested edits based on changes in the upstream
dataset.

Hope this helps!

Nick

On Mon, Jan 28, 2019 at 2:48 AM Rihards  wrote:

> On 27.01.19 21:41, Melanie Mazanec wrote:
> > 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?
>
> Hi, that's really great news - welcome to OSM.
> It would be useful if you would try some basic mapping first to get
> familiar with OSM data structure. Try to map something near your
> workplace or home.
> That doesn't stop you from working on the import, of course. Any
> questions on OSM are welcome on the IRC channel #osm (
> https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> communication channel.
>
> > Thanks,
> > Melanie Mazanec--
>  Rihards
>
> ___
> 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] marciapiedi e strisce pedonali

2019-01-28 Per discussione Cascafico Giovanni

Aggiungerei anche il kerb nella giuntura attraversamento-marciapiede per il
wheelchair routing



Il lun 28 gen 2019, 18:12 Simone Saviolo  ha
scritto:

> Ho un po' di casi simile a quello che descrivi qui:
> https://www.openstreetmap.org/#map=19/45.31836/8.42792
>
> I marciapiedi sono correttamente highway=footway, footway=sidewalk, mentre
> l'attraversamento diventa highway=footway, footway=crossing. Io metto le
> informazioni aggiuntive (soprattutto crossing_ref=zebra|toucan|...,
> supervised=* e lit=*) sul nodo in cui le way dell'attraversamento e della
> strada si incrociano.
>
> Ciao,
>
> Simone
>
> Il giorno lun 28 gen 2019 alle ore 16:30 demon_box <
> e.rossini7...@gmail.com> ha scritto:
>
>> se ho un tratto di marciapiede a sinistra e a destra di una strada
>>
>> highway=footway + footway=sidewalk
>>
>> che poi ad un certo punto "incrociano" un attraversamento pedonale
>> (highway=crossing) che permette di passare da un lato all'altro della
>> strada
>> nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi con
>> una highway=footway oppure cosa?
>>
>> esempio https://www.openstreetmap.org/#map=19/45.55626/10.21816
>> il punto in questione è esattamente al centro
>>
>> ho trovato anche qualcuno che traccia questo collegamento tra i 2
>> marciapiedi e lo tagga per intero highway=crossing ma mi pare proprio che
>> il
>> wiki dica che highway=crossing si utilizza solo su un nodo e non anche su
>> una way.
>>
>> cosa ne pensate?
>>
>> grazie
>>
>> --enrico
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Rendered boundary not present in data

2019-01-28 Per discussione Christoph Hormann


You could try touching (i.e. creating a new version of) both of the 
boundary relations involved - in this case:

https://www.openstreetmap.org/relation/189416

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

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

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione Simone Saviolo

Ho un po' di casi simile a quello che descrivi qui:
https://www.openstreetmap.org/#map=19/45.31836/8.42792

I marciapiedi sono correttamente highway=footway, footway=sidewalk, mentre
l'attraversamento diventa highway=footway, footway=crossing. Io metto le
informazioni aggiuntive (soprattutto crossing_ref=zebra|toucan|...,
supervised=* e lit=*) sul nodo in cui le way dell'attraversamento e della
strada si incrociano.

Ciao,

Simone

Il giorno lun 28 gen 2019 alle ore 16:30 demon_box 
ha scritto:

> se ho un tratto di marciapiede a sinistra e a destra di una strada
>
> highway=footway + footway=sidewalk
>
> che poi ad un certo punto "incrociano" un attraversamento pedonale
> (highway=crossing) che permette di passare da un lato all'altro della
> strada
> nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi con
> una highway=footway oppure cosa?
>
> esempio https://www.openstreetmap.org/#map=19/45.55626/10.21816
> il punto in questione è esattamente al centro
>
> ho trovato anche qualcuno che traccia questo collegamento tra i 2
> marciapiedi e lo tagga per intero highway=crossing ma mi pare proprio che
> il
> wiki dica che highway=crossing si utilizza solo su un nodo e non anche su
> una way.
>
> cosa ne pensate?
>
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione Volker Schmidt

Finora l'uso più frequente è:
highway=crossing
crossing=uncontrolled|traffic_signal|island|unmarked
supervised=no|yes|(orario)default: "no"
crossing_ref (solo UK)
tactile_paving=yes|no!incorrect  (per non vedenti) ancora poco utilizzato
bicyle=no|yes
foot=no|yesdefault "yes"
horse=no|yes default non definito,prsumo che sia "no"
in combinazione con crossing=traffic_signals possono esser messe
button_operated=no|yes
sound_signals:sound=no|yes
Per indicare un passaggio solo bici si utilizza bicycle=no
Il problema con la doppia taggatura del del nodo e del highway che
attraversa è che è possibile taggare in modo contraddittorio, per esempio
sul way:
highway=footway
footway=crossing
e sul nodo
highway=crossing
foot=no


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, 28 Jan 2019 at 16:35, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 28. Jan 2019, at 16:29, demon_box  wrote:
> >
> > nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi
> con
> > una highway=footway oppure cosa?
>
>
> si, highway =footway e footway=crossing
> sulla way dell’attraversamento, mentre highway=crossing sul nodo di
> incrocio con la strada.
>
>
> Il problema che si poneva recentemente in lista tagging era come fare
> quando l’attraversamento è soltanto per le bici. Non è ancora trovata la
> soluzione per questo.
>
>
> Ciao, Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Rendered boundary not present in data

2019-01-28 Per discussione Rafael Avila Coya


Hi, Markus:

I've seen this in a few places too. This is another example in 
Guinea-Conakry:


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

And I tried to force tile rendering, that didn't solve the problem. I 
hope someone may give some light on this.


Cheers,

Rafael.

O 27/01/19 ás 18:31, Markus escribiu:

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



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

Re: [Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione Cascafico Giovanni

Io di solito uso costriure la definizione dal generale al dettaglio, per
cui highway>footway>crossing come in questa way [1] così etichettata:
footway=crossing
highway=footway
surface=sett

[1] https://www.openstreetmap.org/way/661127406



Il giorno lun 28 gen 2019 alle ore 16:35 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 28. Jan 2019, at 16:29, demon_box  wrote:
> >
> > nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi
> con
> > una highway=footway oppure cosa?
>
>
> si, highway =footway e footway=crossing
> sulla way dell’attraversamento, mentre highway=crossing sul nodo di
> incrocio con la strada.
>
>
> Il problema che si poneva recentemente in lista tagging era come fare
> quando l’attraversamento è soltanto per le bici. Non è ancora trovata la
> soluzione per questo.
>
>
> Ciao, Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

Having said that, I still don't understand the objections to addr:town
and addr:village. Can anyone come up with an example of an address
where they wouldn't work? I normally don't care about names but
locality sounds almost offensive.
To me 'locality' just sounds neutral. I don't particularly object to
addr:town and addr:village, but it does mean we end up with at least
three tags rather than one, because in cities suburbs often don't fit
easily into those tags, hence the use of addr:suburb.

Business parks and other campuses are not localities - their names are
written before street names, not after them.
In my experience this often isn't true, perhaps look at more examples.
It is relatively common for business park and industrial estate names to
appear after street names.

Examples:
Lenton Lane Industrial Estate, Nottingham
http://osm-nottingham.org.uk/?z=16=-1.17632=52.93295=OSM,1,15=%22Lenton%20Lane%20Industrial%20Estate%22=SearchOpendataJson=1

Trent Lane Industrial Estate, Castle Donington
http://osm-nottingham.org.uk/?z=16=-1.34152=52.85018=OSM,1,15=%22Trent%20Lane%20Industrial%20Estate%22=SearchOpendataJson=1

Sherwood [Business] Park, Annesley,
http://osm-nottingham.org.uk/?z=16=-1.25353=53.07037=OSM,1,15=%22Sherwood%20Park%22=SearchOpendataJson=1

Regards,
Will

On 28/01/2019 15:06, Andrzej wrote:
Is it possible to use addr:locality for both towns and villages? That
could simplify things quite a bit and I have yet to see an address
that needs a post town and two levels of localities below.

Business parks and other campuses are not localities - their names are
written before street names, not after them. They're IMO what RM calls
"dependent thoroughfares". For these I would simply use addr:place,
which can already be combined with addr:housename and
addr:housenumber. Alternatively we could make a new tag like addr:campus.

Best regards,
Andrzej

On 28 January 2019 20:36:24 GMT+08:00, Colin Smale
wrote:

Hi Will,

On 2019-01-28 13:19, Will Phillips wrote:

Hi,

I agree we need another tag below addr:city for localities. For
this I have usually used addr:suburb when mapping in urban areas
and addr:locality elsewhere. Ideally I think it would be best to
have just one recommended tag, perhaps addr:locality, because
having addr:town addr:village and addr:suburb seems too
complicated. Eventually it would be good if editing software, in
particular iD, could provide an extra field to enter the
locality, and it would perhaps be easier for that to happen if
there was only one tag. New mappers often seem to have difficulty
entering addresses to the form that they wish and I think the
lack of a locality field is part of the reason.

For what Royal Mail calls 'Double Dependent Localities' using
addr:sublocality is a possibility, although I wonder whether just
sticking with addr:village for this less common situation would
be easier. It depends a bit on whether this tag is only likely to
be used for villages and hamlets, or whether it might be useful
in other cases. For example, sometimes names of industrial
estates appear in addresses in a similar way to sublocalities.

I don't see any advantage in "addr:village" and "addr:suburb" just
because they sound familiar or are existing tags. What we are
discussing here is a UK-specific solution. The (Double) Dependent
Localities may or may not correspond to what people perceive as a
"village" or "suburb". In the quoted example, "Cambridge Science
Park" is IMHO neither.

I only use addr:city for post towns, although I recognise not all
mappers agree with this, and I appreciate there are arguments
both ways. I was thinking about this recently when adding
addresses in Lees near Derby. The post town is Ashbourne, but
this seems slightly incongruous because the village is much
nearer to Derby. I chose not to include addr:city and only used
addr:locality for the village name.
I feel the main argument in favour of using post towns for
addr:city is that it helps to keep the data consistent because
what to use often becomes confusing otherwise. To use the example
of Lees I mentioned above, it would be easy to end up with a
situation where addr:city contained perhaps four values if the
data was entered by different people without any guide as to what
to use (the most likely possibilities being Lees, Dalby Lees,
Derby or Ashbourne).
In cases where local residents consider Royal Mail's choice of
post town to be contentious, usually because it is miles from
where they live, it might be sensible to recognise addr:posttown
as an

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione jumbanho

Thanks, that's a very good video.

On Mon, 2019-01-28 at 09:13 -0600, Joe Sapletal wrote:
> If you haven’t seen it already, this was a good presentation from
> SOTM a few months ago about Pedestrian Mapping.  Nick briefly
> discusses the plusses and minuses of adding sidewalk values to the
> existing road way vs creating a way that is the actual sidewalk/path
> that supports a pedestrian network.
>  
> https://2018.stateofthemap.us/program/inclusive-pedestrian-mapping-opensidewalks-accessmap-and-accessibility.html
>  
>  
> Joe Sapletal
>  
> From: jumba...@gmail.com
> Sent: Monday, January 28, 2019 8:37 AM
> To: Joseph Eisenberg; Rihards
> Cc: talk-us@openstreetmap.org
> Subject: Re: [Talk-us] NC sidewalk data import
>  
> I can only speak for the Triangle area, but many sidewalks are mapped
> as separate ways in this area.  It is probably due to the very
> idiosyncratic spending on sidewalks that can begin and end in the
> middle of blocks and frequently do not have connections to the road
> at
> one end or the other.  Trying to split ways and add information on
> connections would lead to very fragmented way.
>  
> Melanie, I know that there was a partial sidewalk import in
> Carrboro/Chapel Hill years ago and there is currently a mapping
> project
> to add sidewalks in the city of Durham which is about halfway
> complete
> (see https://tasks.openstreetmap.us/project/92).  I cannot speak of
> other cities' data, but the City of Durham data has only the sidewalk
> ways themselves and have no connections to streets or other
> infrastructure such as greenways or railways, so a mass import
> without
> careful integration with existing data would not work.  It is a
> fairly
> labor intensive process.  It would be definitely worth your while to
> work on that as you move forward with a broader import project.
>  
> I think the most currently active NC community is on Slack and you
> might get more detailed conversations there.  Here is the nc slack
> link: https://osmus.slack.com/messages/CAM9RBREE and here is the
> triangle link: https://osmus.slack.com/messages/CDW5X3RRD
>  
> James
>  
> On Mon, 2019-01-28 at 21:02 +0900, Joseph Eisenberg wrote:
> > The sidewalk style is somewhat controversial. For routing
> > applications, it is simpler if the sidewalk is added as a tag on
> the
> > highway. This also makes it easier to render clean-looking maps.
> > However, some people prefer to have the sidewalks separately
> mapped,
> > so that they can be seen at high zoom levels in rendered maps.
> >
> > I would suggest checking the current method used in North Carolina,
> > especially in the cities or towns where you plan to add missing
> > sidewalks. It’s probably best to continue using the method that
> local
> > mappers have chosen. This may vary between different towns.
> >
> > Thank you for helping make Openstreetmap even better!
> > On Mon, Jan 28, 2019 at 7:48 PM Rihards  wrote:
> > > On 27.01.19 21:41, Melanie Mazanec wrote:
> > > > 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?
> > >
> > > Hi, that's really great news - welcome to OSM.
> > > It would be useful if you would try some basic mapping first to
> get
> > > familiar with OSM data structure. Try to map something near your
> > > workplace or home.
> > > That doesn't stop you from working on the import, of course. Any
> > > questions on OSM are welcome on the IRC channel #osm (
> > > https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> > > communication channel.
> > >
> > > > Thanks,
> > > > Melanie Mazanec--
> > >  Rihards
> > >
> > > ___
> > > 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
>  
>  
> ___
> 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


___
Talk-us mailing list

Re: [Talk-it] marciapiedi e strisce pedonali

sent from a phone

> On 28. Jan 2019, at 16:29, demon_box  wrote:
> 
> nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi con
> una highway=footway oppure cosa?

si, highway =footway e footway=crossing
sulla way dell’attraversamento, mentre highway=crossing sul nodo di incrocio 
con la strada.

Il problema che si poneva recentemente in lista tagging era come fare quando 
l’attraversamento è soltanto per le bici. Non è ancora trovata la soluzione per 
questo.

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

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

2019-01-28 Per discussione Tom Hughes


On 28/01/2019 15:06, Richard Fairhurst wrote:


The notion that I should tag addresses in Charlbury with "addr:city=Chipping
Norton", a town 6 miles away, just because one private delivery operator[1]
uses Chipping Norton as an optional part of their addressing is... one of
the more outlandish ideas I've heard in OSM tagging circles, and that's
saying a lot.


To be fair "addr:city=Chipping Norton" would be outlandish even for
an address *in* Chipping Norton...

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

[Talk-it] marciapiedi e strisce pedonali

2019-01-28 Per discussione demon_box

se ho un tratto di marciapiede a sinistra e a destra di una strada

highway=footway + footway=sidewalk

che poi ad un certo punto "incrociano" un attraversamento pedonale
(highway=crossing) che permette di passare da un lato all'altro della strada
nel punto dell'attraversamento pedonale devo collegare i 2 marciapiedi con
una highway=footway oppure cosa?

esempio https://www.openstreetmap.org/#map=19/45.55626/10.21816
il punto in questione è esattamente al centro

ho trovato anche qualcuno che traccia questo collegamento tra i 2
marciapiedi e lo tagga per intero highway=crossing ma mi pare proprio che il
wiki dica che highway=crossing si utilizza solo su un nodo e non anche su
una way.

cosa ne pensate?

grazie

--enrico




--
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-ca] Building Import update

2019-01-28 Per discussione Yaro Shkvorets

As far as I know Texas has been using 2 sources for their buildings
imports.

   1. Microsoft, (example:
   https://www.openstreetmap.org/#map=18/32.74517/-97.14334) Even in
   suburbs (that are supposed to be easy for their AI), buildings lack any
   details and sometimes are not even aligned with the roads.
   https://i.imgur.com/eWroYZB.png Some that are in the shades are even
   missing: https://i.imgur.com/8SF3sS4.jpg I can only imagine what it
   looks like downtown. Sure they don't get flagged with "almost square
   angles" but that's pretty much the only thing they have going for them.
   2. OrthoTexas. Much better details but the first place I look, vast
   majority buildings do not have square angles:
   https://www.openstreetmap.org/#map=19/32.97102/-96.78231 Probably even
   worse than in Ontario.

Compared to both of those sources, StatsCan data is much more detailed and
is better aligned with the imagery and surroundings.
If we are so determined to map for the Validator (which I'm not sure is the
right OSM approach) we should fix StatsCan data. I remember there was a
standard JOSM warning for "almost square angles" with autofix a year ago or
so. Does anyone know what happened to it?


On Mon, Jan 28, 2019 at 9:20 AM john whelan  wrote:

> Interesting, although I'm not sure what the best approach is.
>
> 31 Hamilton is interesting.  If you look at the buildings next to it they
> don't have house numbers.  Look at the history and you'll see it was first
> created in 2010 with potlatch and edited once more in 2011.
>
> At my first glance at Kingston the small deviations form 90 degrees did
> not stand out.
>
> I think we can reasonably expect Microsoft to create a Canadian buildings
> file and you seem to be comfortable that the ones it has in the US are of a
> reasonable standard.
>
> Part of my background is large databases and my personal view is the
> minimum data needed the faster the system runs and less data needs to get
> flipped round and backed up.
>
> Could you run the analysis over Ottawa?
>
> Looking closely at a few in Ottawa I note that there are some bay windows
> and other small features I might not have bothered with if mapping with
> JOSM with the buildings_tool. Because of a few 45 degree angles involved
> this isn't something that can be easily solved.
>
> Ottawa I think at some level can be considered a reasonable success.
> Certainly we added a lot of extra information to the building outlines.
>
> I think the trade off is using the municipal data gives us the buildings
> with perhaps more detail than I might like but many would like to see the
> buildings imported.
>
> Dunno (Do not know for translate tools.)
>
> What is the ideal building outline in OpenStreetMap?
>
> What is an acceptable building outline in OpenStreetMap?
>
> Suggestions
>
> Thanks
>
> Cheerio John
>
> On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:
>
>> 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,

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione Joe Sapletal

If you haven’t seen it already, this was a good presentation from SOTM a few 
months ago about Pedestrian Mapping.  Nick briefly discusses the plusses and 
minuses of adding sidewalk values to the existing road way vs creating a way 
that is the actual sidewalk/path that supports a pedestrian network.

https://2018.stateofthemap.us/program/inclusive-pedestrian-mapping-opensidewalks-accessmap-and-accessibility.html

Joe Sapletal

From: jumba...@gmail.com
Sent: Monday, January 28, 2019 8:37 AM
To: Joseph Eisenberg; Rihards
Cc: talk-us@openstreetmap.org
Subject: Re: [Talk-us] NC sidewalk data import

I can only speak for the Triangle area, but many sidewalks are mapped
as separate ways in this area.  It is probably due to the very
idiosyncratic spending on sidewalks that can begin and end in the
middle of blocks and frequently do not have connections to the road at
one end or the other.  Trying to split ways and add information on
connections would lead to very fragmented way.

Melanie, I know that there was a partial sidewalk import in
Carrboro/Chapel Hill years ago and there is currently a mapping project
to add sidewalks in the city of Durham which is about halfway complete
(see https://tasks.openstreetmap.us/project/92).  I cannot speak of
other cities' data, but the City of Durham data has only the sidewalk
ways themselves and have no connections to streets or other
infrastructure such as greenways or railways, so a mass import without
careful integration with existing data would not work.  It is a fairly
labor intensive process.  It would be definitely worth your while to
work on that as you move forward with a broader import project.

I think the most currently active NC community is on Slack and you
might get more detailed conversations there.  Here is the nc slack
link: https://osmus.slack.com/messages/CAM9RBREE and here is the
triangle link: https://osmus.slack.com/messages/CDW5X3RRD

James

On Mon, 2019-01-28 at 21:02 +0900, Joseph Eisenberg wrote:
> The sidewalk style is somewhat controversial. For routing
> applications, it is simpler if the sidewalk is added as a tag on the
> highway. This also makes it easier to render clean-looking maps.
> However, some people prefer to have the sidewalks separately mapped,
> so that they can be seen at high zoom levels in rendered maps.
> 
> I would suggest checking the current method used in North Carolina,
> especially in the cities or towns where you plan to add missing
> sidewalks. It’s probably best to continue using the method that local
> mappers have chosen. This may vary between different towns.
> 
> Thank you for helping make Openstreetmap even better!
> On Mon, Jan 28, 2019 at 7:48 PM Rihards  wrote:
> > On 27.01.19 21:41, Melanie Mazanec wrote:
> > > 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?
> > 
> > Hi, that's really great news - welcome to OSM.
> > It would be useful if you would try some basic mapping first to get
> > familiar with OSM data structure. Try to map something near your
> > workplace or home.
> > That doesn't stop you from working on the import, of course. Any
> > questions on OSM are welcome on the IRC channel #osm (
> > https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> > communication channel.
> > 
> > > Thanks,
> > > Melanie Mazanec-- 
> >  Rihards
> > 
> > ___
> > 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

___
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-ca] Building Import update

2019-01-28 Per discussione Nate Wessel


Hi all,

I was reading about orthogonalization yesterday and came across this 
paper...


https://icaci.org/files/documents/ICC_proceedings/ICC2009/html/refer/19_2.pdf

...which describes an algorithm that seems to quite effectively 
disregard angles that are not close to orthogonal while straightening 
those that are. I added a link to it in the wiki. This may not be 
implemented in JOSM, but there's no reason we couldn't pre-process the 
data in this way.


From Pierre's analysis, it sounds to me like we really do need to 
consider orthogonalizing buildings where possible, which should be 
pretty much all buildings (I could see some buildings sharing nodes 
getting complicated). Once the angles are corrected, I imagine we should 
be able to simplify with a very small threshold and get good results.


Given the number of buildings in this import, this is absolutely 
something worth doing. Four million buildings times one tiny problem 
equals one really huge problem. Let's fix it now while it's still 
relatively easy.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/28/19 9:17 AM, john whelan wrote:

Interesting, although I'm not sure what the best approach is.

31 Hamilton is interesting.  If you look at the buildings next to it 
they don't have house numbers.  Look at the history and you'll see it 
was first created in 2010 with potlatch and edited once more in 2011.


At my first glance at Kingston the small deviations form 90 degrees 
did not stand out.


I think we can reasonably expect Microsoft to create a Canadian 
buildings file and you seem to be comfortable that the ones it has in 
the US are of a reasonable standard.


Part of my background is large databases and my personal view is the 
minimum data needed the faster the system runs and less data needs to 
get flipped round and backed up.


Could you run the analysis over Ottawa?

Looking closely at a few in Ottawa I note that there are some bay 
windows and other small features I might not have bothered with if 
mapping with JOSM with the buildings_tool. Because of a few 45 degree 
angles involved this isn't something that can be easily solved.


Ottawa I think at some level can be considered a reasonable success. 
Certainly we added a lot of extra information to the building outlines.


I think the trade off is using the municipal data gives us the 
buildings with perhaps more detail than I might like but many would 
like to see the buildings imported.


Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

On Sun, 27 Jan 2019 at 23:28, Pierre Béland > wrote:


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

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

2019-01-28 Per discussione Andrzej

Is it possible to use addr:locality for both towns and villages? That could 
simplify things quite a bit and I have yet to see an address that needs a post 
town and two levels of localities below.

Having said that, I still don't understand the objections to addr:town and 
addr:village. Can anyone come up with an example of an address where they 
wouldn't work? I normally don't care about names but locality sounds almost 
offensive. 

Business parks and other campuses are not localities - their names are written 
before street names, not after them. They're IMO what RM calls "dependent 
thoroughfares". For these I would simply use addr:place, which can already be 
combined with addr:housename and addr:housenumber. Alternatively we could make 
a new tag like addr:campus.

Best regards, 
Andrzej 


On 28 January 2019 20:36:24 GMT+08:00, Colin Smale  
wrote:
>Hi Will, 
>
>On 2019-01-28 13:19, Will Phillips wrote:
>
>> Hi,
>> 
>> I agree we need another tag below addr:city for localities. For this
>I have usually used addr:suburb when mapping in urban areas and
>addr:locality elsewhere. Ideally I think it would be best to have just
>one recommended tag, perhaps addr:locality, because having addr:town
>addr:village and addr:suburb seems too complicated. Eventually it would
>be good if editing software, in particular iD, could provide an extra
>field to enter the locality, and it would perhaps be easier for that to
>happen if there was only one tag. New mappers often seem to have
>difficulty entering addresses to the form that they wish and I think
>the lack of a locality field is part of the reason. 
>> 
>> For what Royal Mail calls 'Double Dependent Localities' using
>addr:sublocality is a possibility, although I wonder whether just
>sticking with addr:village for this less common situation would be
>easier. It depends a bit on whether this tag is only likely to be used
>for villages and hamlets, or whether it might be useful in other cases.
>For example, sometimes names of industrial estates appear in addresses
>in a similar way to sublocalities.
>
>I don't see any advantage in "addr:village" and "addr:suburb" just
>because they sound familiar or are existing tags. What we are
>discussing
>here is a UK-specific solution. The (Double) Dependent Localities may
>or
>may not correspond to what people perceive as a "village" or "suburb".
>In the quoted example, "Cambridge Science Park" is IMHO neither. 
>
>> I only use addr:city for post towns, although I recognise not all
>mappers agree with this, and I appreciate there are arguments both
>ways. I was thinking about this recently when adding addresses in Lees
>near Derby. The post town is Ashbourne, but this seems slightly
>incongruous because the village is much nearer to Derby. I chose not to
>include addr:city and only used addr:locality for the village name.
>
>> I feel the main argument in favour of using post towns for addr:city
>is that it helps to keep the data consistent because what to use often
>becomes confusing otherwise. To use the example of Lees I mentioned
>above, it would be easy to end up with a situation where addr:city
>contained perhaps four values if the data was entered by different
>people without any guide as to what to use (the most likely
>possibilities being Lees, Dalby Lees, Derby or Ashbourne).
>
>> In cases where local residents consider Royal Mail's choice of post
>town to be contentious, usually because it is miles from where they
>live, it might be sensible to recognise addr:posttown as an
>alternative.
>
>The accepted paradigm is that the address should represent the postal
>address, and not any administrative relationships. As you will know RM
>have their own particular ideas of the geography of the UK, all done
>for
>their own convenience. It would certainly avoid some confusion if we
>used addr:posttown instead of addr:city.
>
>Regards, 
>Colin
___
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

2019-01-28 Per discussione Richard Fairhurst

Colin Smale wrote:
> As you will know RM have their own particular ideas of the 
> geography of the UK, all done for their own convenience. It 
> would certainly avoid some confusion if we used addr:posttown 
> instead of addr:city.

Fully agree.

The notion that I should tag addresses in Charlbury with "addr:city=Chipping
Norton", a town 6 miles away, just because one private delivery operator[1]
uses Chipping Norton as an optional part of their addressing is... one of
the more outlandish ideas I've heard in OSM tagging circles, and that's
saying a lot.

Richard

[1] https://www.bbc.co.uk/news/business-34514024

--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

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

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione jumbanho

I can only speak for the Triangle area, but many sidewalks are mapped
as separate ways in this area.  It is probably due to the very
idiosyncratic spending on sidewalks that can begin and end in the
middle of blocks and frequently do not have connections to the road at
one end or the other.  Trying to split ways and add information on
connections would lead to very fragmented way.

Melanie, I know that there was a partial sidewalk import in
Carrboro/Chapel Hill years ago and there is currently a mapping project
to add sidewalks in the city of Durham which is about halfway complete
(see https://tasks.openstreetmap.us/project/92).  I cannot speak of
other cities' data, but the City of Durham data has only the sidewalk
ways themselves and have no connections to streets or other
infrastructure such as greenways or railways, so a mass import without
careful integration with existing data would not work.  It is a fairly
labor intensive process.  It would be definitely worth your while to
work on that as you move forward with a broader import project.

I think the most currently active NC community is on Slack and you
might get more detailed conversations there.  Here is the nc slack
link: https://osmus.slack.com/messages/CAM9RBREE and here is the
triangle link: https://osmus.slack.com/messages/CDW5X3RRD

James

On Mon, 2019-01-28 at 21:02 +0900, Joseph Eisenberg wrote:
> The sidewalk style is somewhat controversial. For routing
> applications, it is simpler if the sidewalk is added as a tag on the
> highway. This also makes it easier to render clean-looking maps.
> However, some people prefer to have the sidewalks separately mapped,
> so that they can be seen at high zoom levels in rendered maps.
> 
> I would suggest checking the current method used in North Carolina,
> especially in the cities or towns where you plan to add missing
> sidewalks. It’s probably best to continue using the method that local
> mappers have chosen. This may vary between different towns.
> 
> Thank you for helping make Openstreetmap even better!
> On Mon, Jan 28, 2019 at 7:48 PM Rihards  wrote:
> > On 27.01.19 21:41, Melanie Mazanec wrote:
> > > 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?
> > 
> > Hi, that's really great news - welcome to OSM.
> > It would be useful if you would try some basic mapping first to get
> > familiar with OSM data structure. Try to map something near your
> > workplace or home.
> > That doesn't stop you from working on the import, of course. Any
> > questions on OSM are welcome on the IRC channel #osm (
> > https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> > communication channel.
> > 
> > > Thanks,
> > > Melanie Mazanec-- 
> >  Rihards
> > 
> > ___
> > 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

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

Re: [Talk-ca] Building Import update

2019-01-28 Per discussione john whelan

Interesting, although I'm not sure what the best approach is.

31 Hamilton is interesting.  If you look at the buildings next to it they
don't have house numbers.  Look at the history and you'll see it was first
created in 2010 with potlatch and edited once more in 2011.

At my first glance at Kingston the small deviations form 90 degrees did not
stand out.

I think we can reasonably expect Microsoft to create a Canadian buildings
file and you seem to be comfortable that the ones it has in the US are of a
reasonable standard.

Part of my background is large databases and my personal view is the
minimum data needed the faster the system runs and less data needs to get
flipped round and backed up.

Could you run the analysis over Ottawa?

Looking closely at a few in Ottawa I note that there are some bay windows
and other small features I might not have bothered with if mapping with
JOSM with the buildings_tool. Because of a few 45 degree angles involved
this isn't something that can be easily solved.

Ottawa I think at some level can be considered a reasonable success.
Certainly we added a lot of extra information to the building outlines.

I think the trade off is using the municipal data gives us the buildings
with perhaps more detail than I might like but many would like to see the
buildings imported.

Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

> 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

[OSM-talk-fr] État des routes en temps réel

2019-01-28 Per discussione deuzeffe


Bonjour,

Certes, ce n'est pas nouveau mais :
1/ c'est au fin fond de la France semi-montagneuse ;
2/ c'est basé sur osm et openlayer
3/ ça bouge ^^

C'est https://routes.correze.fr/

La couche « Conditions de circulation » n'est pas activée par défaut, en 
revanche celle des travaux et des déneigeuses, si ! (être un tout petit 
peu patient pour les « voir » se déplacer...)


Enjoy! (or not)
--
deuzeffe

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

Re: [Talk-GB] Mapping Driving Test Centres

2019-01-28 Per discussione Paul Berry

(Moment of reflection.) Sorry, you're right, of course they're not. That'll
teach me to attempt to multitask at work.

As you were.

Regards,
*Paul*

On Mon, 28 Jan 2019 at 12:52, David Woolley 
wrote:

> On 28/01/2019 12:45, Paul Berry wrote:
> > Does https://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddriving_school
> > not fit the bill?
>
> Schools are closer to the poacher than the gamekeeper!  No.  I don't
> think they are equivalent.
>
> > Tag usage here:
> > http://taginfo.openstreetmap.org.uk/tags/amenity=driving_school#map
> >
>
> Says that the tag is not sufficiently used to be mappable!
>
> ___
> 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-us] The San Jose / Santa Clara border

2019-01-28 Per discussione Minh Nguyen


On 2019-01-26 17:13, OSM Volunteer stevea wrote:

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.


Any help maintaining San José’s sprawling, unwieldy city limits would be 
most welcome. A few years ago, I incorporated the Seven Trees 
annexations into San José [1] but didn't go much further to correct the 
crude, outdated data we imported from TIGER.


Thankfully, over the years, Steve has impressed upon me the importance 
of Santa Clara County's Local Agency Formation Commission (LAFCO), which 
serves as the authority on municipal boundaries in the county and 
conveniently releases all its work into the public domain, by virtue of 
being a state agency. The commission's Island Annexation Program page 
[2] links to a memorandum from May 2011 [3] and an atlas from 2015 [4] 
that include detailed maps of the remaining islands.


The county planning department handles GIS for the LAFCO. They have an 
ArcGIS application and layer indicating all the city and town limits in 
the county. [5][6] The planning department is also subject to state 
sunshine laws regarding the public domain.


[1] https://www.openstreetmap.org/changeset/32278082 and 
https://www.openstreetmap.org/changeset/32402544
[2] 
https://www.santaclaralafco.org/specialdistricts/island-annexation-program
[3] 
https://www.santaclaralafco.org/file/IslandAnnexations/Item10A_SanJose.pdf
[4] 
https://www.sccgov.org/sites/dpd/DocsForms/Documents/UrbanIslands_2015_Atlas.pdf
[5] 
https://sccplanning.maps.arcgis.com/home/item.html?id=35968e7124f04807bd1ed70b31fab4fd
[6] 
https://services2.arcgis.com/tcv2cMrq63AgvbHF/ArcGIS/rest/services/PlanningOfficeDataService2/FeatureServer/2


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-GB] Mapping Driving Test Centres

2019-01-28 Per discussione Paul Berry

Does https://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddriving_school not
fit the bill?
Tag usage here:
http://taginfo.openstreetmap.org.uk/tags/amenity=driving_school#map

On Sun, 27 Jan 2019 at 12:08, Mike Baggaley  wrote:

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

Hi Will, 

On 2019-01-28 13:19, Will Phillips wrote:

> Hi,
> 
> I agree we need another tag below addr:city for localities. For this I have 
> usually used addr:suburb when mapping in urban areas and addr:locality 
> elsewhere. Ideally I think it would be best to have just one recommended tag, 
> perhaps addr:locality, because having addr:town addr:village and addr:suburb 
> seems too complicated. Eventually it would be good if editing software, in 
> particular iD, could provide an extra field to enter the locality, and it 
> would perhaps be easier for that to happen if there was only one tag. New 
> mappers often seem to have difficulty entering addresses to the form that 
> they wish and I think the lack of a locality field is part of the reason. 
> 
> For what Royal Mail calls 'Double Dependent Localities' using 
> addr:sublocality is a possibility, although I wonder whether just sticking 
> with addr:village for this less common situation would be easier. It depends 
> a bit on whether this tag is only likely to be used for villages and hamlets, 
> or whether it might be useful in other cases. For example, sometimes names of 
> industrial estates appear in addresses in a similar way to sublocalities.

I don't see any advantage in "addr:village" and "addr:suburb" just
because they sound familiar or are existing tags. What we are discussing
here is a UK-specific solution. The (Double) Dependent Localities may or
may not correspond to what people perceive as a "village" or "suburb".
In the quoted example, "Cambridge Science Park" is IMHO neither. 

> I only use addr:city for post towns, although I recognise not all mappers 
> agree with this, and I appreciate there are arguments both ways. I was 
> thinking about this recently when adding addresses in Lees near Derby. The 
> post town is Ashbourne, but this seems slightly incongruous because the 
> village is much nearer to Derby. I chose not to include addr:city and only 
> used addr:locality for the village name.

> I feel the main argument in favour of using post towns for addr:city is that 
> it helps to keep the data consistent because what to use often becomes 
> confusing otherwise. To use the example of Lees I mentioned above, it would 
> be easy to end up with a situation where addr:city contained perhaps four 
> values if the data was entered by different people without any guide as to 
> what to use (the most likely possibilities being Lees, Dalby Lees, Derby or 
> Ashbourne).

> In cases where local residents consider Royal Mail's choice of post town to 
> be contentious, usually because it is miles from where they live, it might be 
> sensible to recognise addr:posttown as an alternative.

The accepted paradigm is that the address should represent the postal
address, and not any administrative relationships. As you will know RM
have their own particular ideas of the geography of the UK, all done for
their own convenience. It would certainly avoid some confusion if we
used addr:posttown instead of addr:city.

Regards, 
Colin___
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


Hi,

I agree we need another tag below addr:city for localities. For this I 
have usually used addr:suburb when mapping in urban areas and 
addr:locality elsewhere. Ideally I think it would be best to have just 
one recommended tag, perhaps addr:locality, because having addr:town 
addr:village and addr:suburb seems too complicated. Eventually it would 
be good if editing software, in particular iD, could provide an extra 
field to enter the locality, and it would perhaps be easier for that to 
happen if there was only one tag. New mappers often seem to have 
difficulty entering addresses to the form that they wish and I think the 
lack of a locality field is part of the reason.


For what Royal Mail calls 'Double Dependent Localities' using 
addr:sublocality is a possibility, although I wonder whether just 
sticking with addr:village for this less common situation would be 
easier. It depends a bit on whether this tag is only likely to be used 
for villages and hamlets, or whether it might be useful in other cases. 
For example, sometimes names of industrial estates appear in addresses 
in a similar way to sublocalities.


I only use addr:city for post towns, although I recognise not all 
mappers agree with this, and I appreciate there are arguments both ways. 
I was thinking about this recently when adding addresses in Lees near 
Derby. The post town is Ashbourne, but this seems slightly incongruous 
because the village is much nearer to Derby. I chose not to include 
addr:city and only used addr:locality for the village name.


I feel the main argument in favour of using post towns for addr:city is 
that it helps to keep the data consistent because what to use often 
becomes confusing otherwise. To use the example of Lees I mentioned 
above, it would be easy to end up with a situation where addr:city 
contained perhaps four values if the data was entered by different 
people without any guide as to what to use (the most likely 
possibilities being Lees, Dalby Lees, Derby or Ashbourne).


In cases where local residents consider Royal Mail's choice of post town 
to be contentious, usually because it is miles from where they live, it 
might be sensible to recognise addr:posttown as an alternative.


Regards,
Will

On 27/01/2019 20: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

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione Joseph Eisenberg

The sidewalk style is somewhat controversial. For routing applications, it
is simpler if the sidewalk is added as a tag on the highway. This also
makes it easier to render clean-looking maps. However, some people prefer
to have the sidewalks separately mapped, so that they can be seen at high
zoom levels in rendered maps.

I would suggest checking the current method used in North Carolina,
especially in the cities or towns where you plan to add missing sidewalks.
It’s probably best to continue using the method that local mappers have
chosen. This may vary between different towns.

Thank you for helping make Openstreetmap even better!
On Mon, Jan 28, 2019 at 7:48 PM Rihards  wrote:

> On 27.01.19 21:41, Melanie Mazanec wrote:
> > 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?
>
> Hi, that's really great news - welcome to OSM.
> It would be useful if you would try some basic mapping first to get
> familiar with OSM data structure. Try to map something near your
> workplace or home.
> That doesn't stop you from working on the import, of course. Any
> questions on OSM are welcome on the IRC channel #osm (
> https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
> communication channel.
>
> > Thanks,
> > Melanie Mazanec--
>  Rihards
>
> ___
> 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-ph] Request for clarification on road tagging guidelines

2019-01-28 Per discussione Eugene Alvin Villar

On Mon, Jan 28, 2019, 7:12 PM grab osm via talk-ph <
talk-ph@openstreetmap.org wrote:

> But, how would we go about when we find a missing connector.  Will it be a
> good idea to tag it as highway = road?
>

Tag it with either the minor road type or the major link type. You can also
look at surrounding areas to see which tagging is usually used. Either
would be more correct than highway=road which is intended as just a
temporary value.

~Eugene

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

Re: [Talk-us] NC sidewalk data import

2019-01-28 Per discussione Rihards

On 27.01.19 21:41, Melanie Mazanec wrote:
> 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?

Hi, that's really great news - welcome to OSM.
It would be useful if you would try some basic mapping first to get
familiar with OSM data structure. Try to map something near your
workplace or home.
That doesn't stop you from working on the import, of course. Any
questions on OSM are welcome on the IRC channel #osm (
https://wiki.openstreetmap.org/wiki/IRC ), or any other OSM
communication channel.

> Thanks,
> Melanie Mazanec-- 
 Rihards

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

Re: [Talk-de] Overpass Abfrage

2019-01-28 Per discussione Martin Scholtes

Hallo Roland,

das ist nun total verrückt, hatte gestern versucht mit dem area Wert
eine Ausgabe liefern zulassen und es klappte nicht.
Aber danke fürs drüber schauen.

Gruß

Am 28.01.2019 um 10:52 schrieb Roland Olbricht:
> Hallo,
>
> area[name="Rettungsdienstbereich Trier"];
> out tags;
>
> hat den folgenden Fund:
>
>   
>     
>     
>     
>     
>     
>   
>
> und
>
> (
>   node[amenity=nursing_home](area:3604168993);
>   way[amenity=nursing_home](area:3604168993);
>   relation[type=multipolygon][amenity=nursing_home](area:3604168993);
> );
> out count;
>
> hat zumindest 1 Treffer. Gemäß Gegenprobe mit
>
> node[highway=bus_stop](area:3604168993);
> out count;
>
> und 1641 Treffern spricht vieles dafür, dass rund um Trier wohl nur 1
> Objekt mit dem Tag "amenity=nursing_home" versehen ist.
>
> Viele Grüße,
> Roland
>
-- 
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

2019-01-28 Per discussione Roland Olbricht


Hallo,

area[name="Rettungsdienstbereich Trier"];
out tags;

hat den folgenden Fund:

  





  

und

(
  node[amenity=nursing_home](area:3604168993);
  way[amenity=nursing_home](area:3604168993);
  relation[type=multipolygon][amenity=nursing_home](area:3604168993);
);
out count;

hat zumindest 1 Treffer. Gemäß Gegenprobe mit

node[highway=bus_stop](area:3604168993);
out count;

und 1641 Treffern spricht vieles dafür, dass rund um Trier wohl nur 1 
Objekt mit dem Tag "amenity=nursing_home" versehen ist.


Viele Grüße,
Roland


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

Re: [Talk-de] Overpass Abfrage

2019-01-28 Per discussione Roland Olbricht


Hi,


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.


Grundsätzlich geht das mit "convert", hat aber gewollte Einschränkungen.
Beispiel:

(
node[amenity=nursing_home]({{bbox}});
way[amenity=nursing_home]({{bbox}});
relation[type=multipolygon][amenity=nursing_home]({{bbox}});
);
convert poi ::geom=geom(),name=t["name"];
out center;

Als Seiteneffekt kommen dann statt Objekten vom Typ z.B. "way" solche 
mit dem Tagnamen "poi" heraus. Außerdem sieht die Geometrie etwas anders 
aus. Im JSON-Modus ist die Geometrie GeoJSON-konform, im XML-Modus eine 
Übersetzung davon.


Der Grund ist, dass ich vermeiden möchte, dass jemand Tags abschneidet 
oder umschreibt und die Daten wieder hochlädt. Die Datenstrukturen 
sollten also hinreichend anders aussehen, um Wiederhochladen nach dem 
automatischen Umschreiben zu verhindern. Bei den produzierten Formaten 
ist noch Gestaltungsspielraum, so dass ich für Rückmeldung insbesondere 
zu Anwendungsfällen dankbar bin.


Mit dem Ausrufezeichen kann man noch Keys ausschalten, falls man nicht 
nur eine Positivliste möchte:


convert poi ::geom=geom(),::=::,!name;

Referenz:
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#The_statement_convert

Es gibt zwei Blogbeiträge zu dem Thema:

https://dev.overpass-api.de/blog/final_0_7_54.html
befasst sich mit convert

https://dev.overpass-api.de/blog/flat_world.html
befasst sich mit der Geometrie in diesem Zusammenhang.
Und ich ergebe nicht den Anspruch, Großkreise toll berechnen zu können, 
sondern es geht darum, wie ich abzufangen versuche, dass GeoJSON im 
Gegensatz zu OSM die Erde als flaches Rechteck betrachtet.


Viele Grüße,
Roland

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

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

2019-01-28 Per discussione Vitor George

Oi pessoal,

Antes de disponbilizar as imagens do PLEAIDES para os mapeadores de
OpenStreetMap, é preciso documentar os termos de uso na wiki conforme
descrito no post do blog.

Uma imagem do Sentinel, que tem autorização de uso no OSM documentada, já
foi utilizada para mapear a area de impacto:

https://www.openstreetmap.org/relation/9265573

Abraços,
Vitor


On Sat, Jan 26, 2019 at 11:29 PM 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

[OSM-talk-fr] hebdoOSM Nº 444 2019-01-15-2019-01-21

Bonjour,

Le résumé hebdomadaire n° 444 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

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

Bonne lecture !

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

[Talk-ca] hebdoOSM Nº 444 2019-01-15-2019-01-21

Bonjour,

Le résumé hebdomadaire n° 444 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

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

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
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-ht] hebdoOSM Nº 444 2019-01-15-2019-01-21

Bonjour,

Le résumé hebdomadaire n° 444 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

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

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[Talk-africa] hebdoOSM Nº 444 2019-01-15-2019-01-21