Re: [Talk-se] Gammal nedlagd stig på Härjarö

[Peter Svensson]

Om det idag går att skönja (och följa) en stig i naturen: komplettera
highway=path med trail_visibility=intermediate/bad/horrible beroende på hur
illa det är.  https://wiki.openstreetmap.org/wiki/Key:trail_visibility

Om det inte går att skönja något som helst spår i naturen på marken längre
på någon del av stigen: ersätt highway=path med note="former path is
completely non-existing on ground as of survey 2023-07-21, please do not
re-add to map without resurvey" eller liknande budskap om det finns risk
att den läggs till från gamla flygfoton/kartor igen.


Den fre 21 juli 2023 kl 16:08 skrev bengt bäverman :

> På Härjarö finns en gammal stig (207166902 eller
> https://www.openstreetmap.org/search?whereami=1=59.48334%2C17.40647#map=17/59.48334/17.40648)
> inlagd och markerad som:
> highway=path
> source=historical
> source_ref=ekonomiska kartan
>
> Stigen är en gammal övergiven stig som en gång har varit markerad och
> sannolikt ingått i Upplandsleden.* Idag går det inte att gå den stigen
> längre*. Om någon skulle kartlägga området idag skulle den aldrig bli
> inlagt som en stig. Naturen har tagit tillbaka den och Upplandsleden går
> inte där längre.
>
> Vilka attribut ska denna stig ha? Ska den finnas kvar?
>
> Jag antar att det borde markeras med:
> highway=abandoned
>
> eller möjligen
> disused:highway=path
> men enligt beskrivning av disused så är för saker som i huuvudsak
> fungerar, men inte längre används.
>
> Alternativt kan den helt tas bort. Som det är nu så renderas den på kartan
> och lurar människor att gå där. Mig till exempel :-). Det var trassligt att
> ta sig tillbaka...
>
> vänligen
>Bengt
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Import av laddstationer

[Peter Svensson]

Här finns länk till importprojektet "Nordic Charging Station Import" och en
påbörjad dialog med riiga:
https://www.openstreetmap.org/changeset/133802584#map=6/61.081/14.265

Den sön 19 mars 2023 09:32Magnus Bäck  skrev:

> Jag tog en snabbtitt på Skåne (
> https://www.openstreetmap.org/changeset/133798156#map=9/55.9210/13.8718)
> och det verkar vara väldigt blandat kvalité; ibland helt off och baserat på
> centrumpunkten på den POI som laddningsstationen är till för  och ibland
> gett namn åt (t.ex. https://www.openstreetmap.org/node/10742002833) men
> ibland nästan lika bra som om den varit manuellt utplacerad. Duplikat av
> befintliga noder förekommer också.
>
> Hur ser licenssituationen ut för Nobil-datan?
>
> -Magnus
>
> On Sun, Mar 19, 2023 at 8:29 AM Peter Svensson 
> wrote:
>
>> Måste vara denna du menar:
>>
>> https://www.openstreetmap.org/changeset/133837916
>>
>> Skriver du en relevant och saklig changeset-kommentar?
>>
>> Dessa changesets bör granskas också:
>>
>> https://www.openstreetmap.org/user/riiga/history/
>>
>> Det ser ut att vara en nationell import som berör hela Sverige.
>>
>> Mvh
>>
>> Den sön 19 mars 2023 08:08Snusmumriken 
>> skrev:
>>
>>> Jag reverterade precis en stor import av laddstationer i Stockholm som
>>> gjordes igår. Främst p.g.a. att placeringen av stationerna inte stämde
>>> överens överhuvudtaget med verkligheten. Vidare bör en import
>>> diskuteras i förväg.
>>>
>>> ___
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>>>
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Import av laddstationer

[Peter Svensson]

Måste vara denna du menar:

https://www.openstreetmap.org/changeset/133837916

Skriver du en relevant och saklig changeset-kommentar?

Dessa changesets bör granskas också:

https://www.openstreetmap.org/user/riiga/history/

Det ser ut att vara en nationell import som berör hela Sverige.

Mvh

Den sön 19 mars 2023 08:08Snusmumriken 
skrev:

> Jag reverterade precis en stor import av laddstationer i Stockholm som
> gjordes igår. Främst p.g.a. att placeringen av stationerna inte stämde
> överens överhuvudtaget med verkligheten. Vidare bör en import
> diskuteras i förväg.
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Importera byggnadshöjder där dessa saknas?

[Peter Svensson]

Jag tror de som kör flygsimulatorer skulle bli överlyckliga!

En förutsättning är såklart guideline för import följs:
https://wiki.openstreetmap.org/wiki/Import/Guidelines

mvh

On Tue, Mar 15, 2022 at 10:33 AM Anders Torger  wrote:

> Jag tycker det låter som en utmärkt idé. Ju mer data som finns i OSM
> desto mer saker kan databasen användas till.
>
> /Anders
>
> On 2022-03-15 10:23, Christian Asker wrote:
> > Hej kära karterare. Jag vet inte ifall jag ska fråga här eller i
> > facebook-gruppen för OSM-Sverige, men jag börjar här i alla fall.
> >
> > Jag heter Christian Asker och karterar en del för OSM på fritiden. I
> > mitt arbete som forskare i luftmiljö på SMHI använder vi OSM-data både
> > här och där. Bland annat använder vi byggnader för att modellera
> > luftmiljön i gaturum i städer. En osäkerhet här är att många byggnader
> > i OSM saknar byggnadshöjd.
> >
> > Som ett led i ett projekt kikar vi nu på att plocka byggnadshöjder
> > från Lantmäteriets Laserdata skog. Än så länge täcks bara delar av
> > Sverige av denna laserdata, men det är åtminstone bättre än det vi har
> > nu.
> >
> > Frågan är nu: när vi ändå beräknar byggnadshöjder, ska vi kanske
> > importera dessa till OSM, för de byggnader som saknar höjd-info idag?
> > Licensen på datat från LM är CC0, så den ska vara kompatibel med OSM.
> > Troligen kommer det handla om att plocka höjden i centroid-punkten för
> > varje byggnad. Troligen får man även filtrera bort små byggnader.
> >
> > Importen innebär alltså inte att man lägger till byggnader som inte
> > redan finns i OSM, utan endast "height"-taggen där denna saknas. Så;
> > är detta intressant för OSM?
> >
> >
> > Mvh Christian Asker (OSM: ChristianA)
> >
> >
> >
> > ___
> > Talk-se mailing list
> > Talk-se@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-se
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-au] Betty's Burgers - fast food or restaurant?

[Peter Hardy]

Betty's Burgers & Concrete Co? I've eaten at the one on Clarence St and the one 
in Darling Harbour in Sydney (admittedly before *waves arms around* all of 
this, so a couple years ago). They're fast food with dine-in tables - order at 
the register.

On Wed, 9 Feb 2022, at 10:06 PM, Mat Attlee wrote:
> I am currently on holiday and stumbled upon the chain that is Betty's 
> Burgers. I didn't go inside so could anyone tell me if these are restaurants 
> or fast food outlets where you order at the counter? I've had a look at ones 
> already mapped and they aren't tagged consistently.
> 
> Happy to create an entry in the name suggestion index as I see there is 
> already a Wikidata entry.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
> 
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] How to properly add address tags when multiple buildings share a housenumber?

[Peter leGras]

Hi Peter,
If you are tagging unit addresses in Orange NSW, I see a lot (but not all)
of strata complexes actually have the address with unit number in the NSW
spatial services addressing theme, despite not being displayed in the DCS
NSW Base Map layer.
This is a useful data source where there is restricted access, especially
in strata.
We have a waiver to use spatial services data such as this.
https://portal.spatial.nsw.gov.au/portal/home/webmap/viewer.html?useExisting=1=d3cf7c7edef14ca18248c6dc5fcaff96
Hope you find it useful.
I am mapping in the Blue Mountains and have done a bit of work in Orange. A
few nearby mappers are active in the OSM World discord server that was
mentioned recently in the talk-au list if you'd like to join us for casual
discussion.
Cheers
other Peter (2hu4u)

On Sun, 16 Jan 2022 at 23:20, Peter leGras  wrote:

> Hi Peter,
> The tag addr:housenumber does not render on non-building areas, but it is
> still useful to include on the complex lot bounds to assist geocoding. You
> can read more about this at
> https://github.com/gravitystorm/openstreetmap-carto/issues/1746
> Note that adding a node tagged with addr:housenumber at the centre of the
> complex will render on osm.org.
> If there are multiple dwellings on the complex with the same housenumber,
> you could add the addr:housenumber to every dwelling in the lot and
> consider adding addr:unit or addr:flats to each as necessary.
> Cheers
> 2hu4u
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] How to properly add address tags when multiple buildings share a housenumber?

[Peter Hardy]

Hey Peter.

On Sun, 16 Jan 2022, at 11:20 PM, Peter leGras wrote:
> The tag addr:housenumber does not render on non-building areas, but it is 
> still useful to include on the complex lot bounds to assist geocoding. You 
> can read more about this at 
> https://github.com/gravitystorm/openstreetmap-carto/issues/1746
> Note that adding a node tagged with addr:housenumber at the centre of the 
> complex will render on osm.org.

Good to know! Thank you.

Looking at https://wiki.openstreetmap.org/wiki/Key:addr more carefully, it does 
say that adding an address to a node within the site outline is fine, thanks 
for the pointer. I'm a little wary of tagging the same housenumber on the site 
way and a node, as josm throws a validation warning (and a lot of my edits have 
been around removing validation problems ;) ). But I think I can see how this 
might be a valid use.

> If there are multiple dwellings on the complex with the same housenumber, you 
> could add the addr:housenumber to every dwelling in the lot and consider 
> adding addr:unit or addr:flats to each as necessary.

Oh, `addr:unit` looks like it could be a good option. Unfortunately, for a lot 
of these I don't have ready access to the unit numbers - at the end of the day 
they're on private property so I'd be inferring the majority based on what I 
can see from the footpath - so was planning on just mapping the street address 
for the lot.

Thanks,
-- 
Peter___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] How to properly add address tags when multiple buildings share a housenumber?

[Peter leGras]

Hi Peter,
The tag addr:housenumber does not render on non-building areas, but it is
still useful to include on the complex lot bounds to assist geocoding. You
can read more about this at
https://github.com/gravitystorm/openstreetmap-carto/issues/1746
Note that adding a node tagged with addr:housenumber at the centre of the
complex will render on osm.org.
If there are multiple dwellings on the complex with the same housenumber,
you could add the addr:housenumber to every dwelling in the lot and
consider adding addr:unit or addr:flats to each as necessary.
Cheers
2hu4u
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] How to properly add address tags when multiple buildings share a housenumber?

[Peter Hardy]

Hey folks.
I'm just getting started contributing to OpenStreetMap, adding address 
information for my local area. I've just started working in an area with heavy 
residential subdivision; blocks being split with several freestanding 
dwellings. There's a fairly pathological example at 
https://www.openstreetmap.org/#map=19/-33.28505/149.08483 , but there's a lot 
of smaller subdivisions around it.

The wiki at 
https://wiki.openstreetmap.org/wiki/Addresses#Multiple_buildings_for_one_housenumber
 suggests adding a perimeter and addr tags to it. And a little further digging 
around I found 
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential#Apartment_Complexes
 , which suggests `landuse=residential` is appropriate for this sort of use. So 
I created an area around the property boundary based on the NSW DCS Base Map, 
added `landuse=residential`, then appropriate `addr:housenumber` and 
`addr:street` tags.

JOSM renders this how I'd expect, with an outline around the area and the 
housenumber displayed in the middle of the area. But the map tiles I see on 
opnstreeetmap.org only show the outline of the area, and do not display a 
housenumber.

Is this the right approach for doing this? Am I just missing something stupid 
to get this to work, or should I drop this plan and just stick to numbering the 
building closest to the street?

Thanks for any advice,
-- 
Peter___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-transit] Mapping train services in Great Britain

[Peter Hicks]

Hello!

Services on Network Rail infrastructure have a set of timing points and
arrival and/or departure or passing times at these locations.  Services
must include a timing point at every location where it stops, plus
mandatory locations - so you will see all trains with a time at Watford
Junction regardless of whether they stop or not.  However, you won't see
any trains at Kings Langley (one stop north) apart from ones that don't
stop, because it isn't a mandatory timing point.

Services may also call at the same stations but take a different route on
particular days, and the concept of a 'route' is really hard to define
anyway.  Is a service from London Euston to Tring (destination) a "route"?
What about a service that runs from London Euston to Milton Keynes Central,
further down the line?  Is the Euston - Tring "route" a duplicate of the
Euston - Milton Keynes "route"?  If not, what about a Euston - Edinburgh
service?  Would a Euston - Tring service be part of that "route" too?

I agree with Mark that this is best kept out of OSM.  In the rail industry,
we don't really have a strict concept of a 'route' in train service terms,
only a set of timing points.

Peter Hicks
Director
OpenTrainTimes Ltd.


On Mon, 31 May 2021 at 14:38, Mark Lester via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> Wiring services directly into the map has obvious maintenance problems.
> Keeping the map aligned with timetable changes clearly isn't feasible. I
> don't believe this data belongs in the map proper.
> Using a route planner to calculate bus routes is feasible. I did a lot of
> work on this. It's all in JavaScript on Node. I can handle any public GTFS,
> you need to rationalize them extensively, they can be vast.
> Doing this for railways turns out to be much harder. You get trains doing
> crazy things at mega stations, you have to work out where the platforms are
> etc. It would be quite useful in the US where most of the network doesn't
> carry passenger services, or Argentina where there is an enormous network
> mapped which is largely derelict or just carries cattle.
> I was developing combined vector and raster tiles to support interactive
> network maps to any resolution. So you can zoom out and hover over the east
> coast mainline and get principal services highlighted. Or over a city and
> get to interrogate an otherwise impenetrable bus map. We have a transparent
> vector tile up to a limit laid over a full res raster.
> I gave up as I couldn't find anyone interested. The bus mapping was going
> very well, you just can't give this stuff away. The railways needs
> significant input from route planning guys to do this.
>
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, 31 May 2021 at 18:17, Tony Shield
>  wrote:
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>

-- 


OpenTrainTimes Ltd. registered in England and Wales, company no. 
09504022.
Registered office: Suite 1-3, Hop Exchange, 24 Southwark Street, 
London SE1 1TY

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

Re: [Talk-GB] UK street addressing

[Peter Neale via Talk-GB]

At the risk of throwing another edge case into the pot (and mixing metaphors), 
can I ask how I should tag our flat?
The Post Office Official postcode checker renders it as:
Flat  
where  refers to the whole block and is common to all the flats.
I cannot see what the Post Office is calling the various data fields, but I 
assume OSM would be happy with (taking elements from above) 
addr:housenumber=addr:street=addr:city=
addr:postcode=
That just leaves me to deal with the "Flat" element.
Consulting the Wiki, I THINK I can cover that with:
add:flats=  (for one specific flat)
...or addr:flats= (for the whole block)
However, I unsure whether to include the word "Flat" in the value field of 
"addr:flats=*", or not.  The Wiki page for Key:addr includes, as an example, 
"addr:flats=Suite 110A", which seems fine for a single living space unit.  It 
could be called "Flat 110A", "Suite 110A", "Apartment 110A", etc., so including 
the descriptor word could be useful to the data consumer.  However, the Wiki 
page for Key:addr:flats shows only numeric values. 
TagInfo shows 203.5k uses of "addr:flats", but only 38 uses of 
"addr:flats=*flat*" and 42 uses of "addr:flats=*suite*", again suggesting that 
only the unique value(s) (e.g. "1", "2", "13B", etc.)  are sufficiently used to 
warrant data consumers catering for them. 
So, should I omit the word "Flat", "Suite", "Apartment" etc., leaving the data 
consumer to guess (or to default to "Flat...")?

Regards,Peter

On Monday, 21 December 2020, 09:30:37 GMT, Robert Whittaker (OSM lists) 
 wrote:  
 
 Like it or not, in the UK addresses are defined by Royal Mail. They're
introduced the concept of a "postal town", and this is one of the few
common elements that each address must always have. Once you accept
that the Post Town is intended to be a nearby significant place (to
help with delivery routing and identifying the rough location of the
addressed property) rather than being a place that the address is
"in", then it's really no more of a fiction than the postcode. (The
village I grew up in had a GL postcode, despite it being in
Worcestershire. I've currently got an IP postcode, despite being in
Norfolk and closer to Norwich (NR) than Ipswich.)

On the basis that it's a required part of each address, I would
recommend that we do store the post town in OSM addresses. There are
significant advantages to storing it in a consistent way, and the best
existing tag to do this would be addr:city. (We wouldn't want to
invent a new tag (e.g. addr:posttown), since as a UK-only term that
will simply be ignored by most international data consumers.

We then have a possible hierarchy of named localities between the
street and the post town to record as part of the address. I would
suggest using appropriate values from the set {addr:hamlet,
addr:village, addr:town, addr:suburb}. (I don't see any other
alternatives to this.) Most of these key names already have a
reasonable number of uses in OSM (addr:town is the lowest, but that
still has 59k uses), so it seems that others are doing this too.

Regarding properties (e.g. on named terraces or sub-streets), where
there are two street names (Thoroughfare and Dependent Throughourfare
in Rail Mail terminology) then we need a second key to store the other
street name under. Certainly if there is an addr:housenumber or
addr:housename, I think we need to use addr:street for the
street/terrace name on which that name or number applies. Otherwise,
software that's unaware of the second key name will think it's house
number n on the main street not the sub-street. There are already
about 3.5k uses of addr:parentstreet in OSM, so I'd recommend using
that for the main street, and addr:street for the terrace or
sub-street name. If any data-users aren't aware of addr:parentstreet
it's not a major issue, since it will still pick up the correct
terrace/sub-street name, and the locality, which will probably be
enough to use as an address.

I would strongly argue against using addr2 in connection with
sub-streets, as it's not standardised, and is likely to not be picked
up by any software. There's an abondoned proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/addr2 , but that
was for the case of a single property on a street corner having two
formal addresses, one on each street, not for the case of two streets
in a hierarchy.

Robert.

On Sun, 20 Dec 2020 at 12:47, Dave Abbott  wrote:
> I am trying to make sure I tag addresses correctly. I am currently
> trying to understand how to map in my area.
>
> The postal addresses are like:
>
> 99 Postal Street
> Smalltown
> Largertown
> West Yorks XY9 7GY
>
> Smalltown is geographically separate to Largertown, which however is the
> Postal Town. Omitting Smalltown fro

Re: [Talk-GB] UK street addressing

[Peter Neale via Talk-GB]

Postal Town may be "mandatory", but it is not really needed.
When presenting a parcel at my local post office recently, to be sent by the 
"signed for" service, they wanted to have the senders address on the reverse, 
so that it could be used as a return address, in the event of non-delivery.
All I had to (hurriedly) write was the Housenumber and Postcode (no 
PostalStreet, no PostalDistrict, no PostalTown)
Regards,Peter


On Sunday, 20 December 2020, 15:00:31 GMT, Colin Smale 
 wrote:  
 
 
On 2020-12-20 15:41, Chris Hill wrote:

Addresses in OSM are not the same as Royal Mail's addresses. RM addresses are 
all about their processes for delivering post to delivery points. The postal 
town (Largertown in your example) is a convenience for RM that we have all been 
persuaded is useful, but RM have ceased to use postal towns for many years! 
Are you not thinking of Postal Counties? They were indeed deprecated many years 
ago (1996), but the Post Town is AFAIK a mandatory component of a postal 
address, and Wikipedia agrees: https://en.wikipedia.org/wiki/Post_town 
___
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] Mapping a single Royal Mail mailbox with two references

[Peter Neale via Talk-GB]

The Wiki says,
"Sometimes several post boxes are standing together and can most often be 
tagged with one single node. If the boxes have different reference numbers this 
is tagged as ref=12242;23214. You can also use two separate nodes in such 
cases, which may be more appropriate if the boxes are two separate physical 
entities. It would also be necessary to use two nodes if the two boxes had 
different collection times or item restrictions and you wanted to tag these 
differences."
So, if their type and collection times are the same, I think you can choose to 
tag 2 separate nodes, or one node with 2 refs, separated by a semi-colon.
Regards,Peter


On Monday, 14 December 2020, 13:51:24 GMT, Mat Attlee 
 wrote:  
 
 What's the most appropriate way to map a single physical Royal Mail mailbox 
with two signs and references? I recently stumbled upon such a mailbox and 
created a POI for each sign / reference:

https://www.openstreetmap.org/node/8214997322https://www.openstreetmap.org/node/8215022917
However given the collection times are the same and it is just one physical 
mailbox would it be better to have a single POI with two 
references?___
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] driveway-becomes-track

[Peter Neale via Talk-GB]

IMHO, if it leads on to another road, track, etc. it is not a "driveway", but 
could be a track, a bridleway, a service road, or something else.
The Wiki says that a driveway is (with my bold for emphasis), 
" ... a minor service road leading to a residential or business property. It 
typically branches from a bigger road and leads toward an entrance to a 
specific destination (building, etc.). It may end at or pass the entrance, but 
either way, it gets close to its destination. It is rare for a driveway to be 
the way to access another roadway (but see Pipestems below)."
(pipestems allow a driveway to be shared between several properties)
So if, in this case, it leads on to another way (e.g. a bridleway, or a track), 
it is not a driveway.  Does this solve the problem?
Regards,Peter
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb 

On Sunday, 13 December 2020, 10:25:46 GMT, Edward Bainton 
 wrote:  
 
 Sorry, I joined this thread late and I see the initial query was, How to 
ensure tracks don't just pop up nowhere'. So driveway first then track doesn't 
solve the problem.
That makes me say track all the way, as someone else has said. The different 
surfaces can be caught in the attributes.
On Sun, 13 Dec 2020 at 10:08, Edward Bainton  wrote:

>  https://85a.uk/noverton_farm_1280x800.jpg
>
> It seems daft to me that the mud gets rendered but not the hardcore. If
> I change the "driveway" to "track" that would be the dreaded tagging for
> the renderer would it not? Generally in this part of the world "track"
> means mud, rather than a roadway suitable for all vehicles.

I don't know what part of the world you're in, but by my Fenland lights, I'd 
probably call that a track, not a driveway - certainly once it passes the farm 
buildings (since I see a driveway as implying car-worthy access to a building). 
Would that solve it? Driveway as far as the farm and then track?
I'm going to risk blasphemy and suggest that tagging for the renderer is what 
we all do, all day (or why map?). The problem imo is "fudging it for the 
renderer", or "outright lying for the renderer". In this case, I'd say track is 
a valid choice - I think even for the whole length, if by "driveway" we infer 
something, short, tidy, and suburban.
But I'm still a spring chicken round here, relatively speaking, and I await 
correction by my olders.
On Sun, 13 Dec 2020 at 09:09, Nick Whitelegg via Talk-GB 
 wrote:

>Getting back to this case, this is the farm drive. Beyond the
>cattle-grid the public bridleway continues left through the farm
>buildings, and the surface deteriorates to the usual farm mud:

  >https://85a.uk/noverton_farm_1280x800.jpg


Apologies for going off topic, but I knew that name (Noverton Farm) sounded 
familiar.
A quick check of where it is would explain why. In 1998 I did a  long distance 
walk from Sussex to the Peak District, following ordinary footpaths (planned 
using OS maps) and went through this area, the Teme Valley. It was very 
nicebut​ the footpaths were in an appaling state of disrepair, I remember on 
several occasions that day having to scramble through dense shrub cover and 
attempt to negotiate barbed-wire fences. I seem to recall Noverton Farm as 
being the site of some particularly badly-maintained footpaths.
As an aside this walk is what indirectly got me into OSM. I wanted to 
illustrate the walk on the internet but OS licensing did not permit it, which 
is how I started Freemap and then later got involved with OSM. I still haven't 
illustrated this walk incidentally, but...
Would be interested to find out if the area has improved since..
Nick



From: Martin Wynne 
Sent: 12 December 2020 14:30
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] driveway-becomes-track On 12/12/2020 13:15, Andy 
Townsend wrote:

> 
> Ultimately, if "something needs doing", "someone" will need to do it. 
> Perhaps that someone is you?

Hi Andy,

Yes that someone could be me. I have a server (located in Columbus, 
Ohio) on which I am using only a fraction of the available memory space 
and bandwidth. I have been thinking of making better use of it, possibly 
by hosting something from OSM.


 >  I'd suggest setting up a copy of the
 > standard map rendering as per https://switch2osm.org/serving-tiles/
 > (just for Worcestershire would be fine) and start tinkering with the
 > logic that decides what sort of service road is what, such as
 > 
https://github.com/gravitystorm/openstreetmap-carto/blob/b10aef3866bacf387581b8fea4eec265010b0d14/project.mml#L475



Thanks. I have been looking at https://switch2osm.org/serving-tiles/ but
I have a lot to learn. I can do Windows programming, but on stuff for 
the web I'm only a dabbler. I looked at Mapnik and saw interfaces only 
for Python and C. If that had been Pascal, I would have dived in by now.

I 

[Talk-de] Fwd: Flussrelationen: Mitglieder und deren Reihenfolge

[Franz-Peter Boley]

Moin,

ich hab mir im Rahmen des Schwerpunktes der Woche [0] mal die
Flussrelation der Ems [1] angeschaut und mir sind zwei Fragen gekommen:

Welche Segmente gehören in die Relation?

Es sind weite Teile des Dortmund-Ems-Kanals auch in der Relation samt
Schleusen. Diese Liniensegmente sind aber definitiv nicht natürlichen
Ursprungs und nicht Teil des Flusses Ems. Zumindest nach meinem
intuitiven Verständnis her dürften sie daher nicht Teil der Relation
sein oder gibt es gute Argumente es doch zu tun?
Ich würde den Dortmund-Ems-Kanal in eine eigene Relation packen. Das
sind für mich zwei unterschiedliche Wasserwege.

Ist eine Reihenfolge der Liniensegmente wichtig?
Nach meinem Verständnis nein.

Ist das in einer waterway-Relation relevant? Zumindest die "main_stream"
Segmente würde ich in eine Reihenfolge bringen, damit es ordentlich
aussieht.
Ich habe die main_stream Segmente in der Relation immer fortlaufend in
der Reihenfolge des Flusses eingeordnet, side_streams am Ende nach den
main_stream Segmenten. Dann sieht man im Relationseditor sofort, ob
main_stream Segmente in der Relation fehlen.

Aber Nebenströme? Würde ich möglichst an die Stelle in der Liste der
Segmente packen an der sich der Nebenstrom auch befindet. Oder gibt es
dazu Gegenargumente?
Bin mir nicht sicher, was Du unter Nebenströmen verstehst. In die
Relation kann man side_streams packen, das sind Nebenarme, die vom
main_stream abgehen und später wieder zurück in den main_stream münden.
Nebenflüsse (tributaries) nehme ich nicht in die Relation auf.

Das Wiki sagt dazu leider nichts, hat jemand Meinungen?

Viele Grüße
Hauke

[0] https://wiki.openstreetmap.org/wiki/DE:Schwerpunkt_der_Woche
[1] https://www.openstreetmap.org/relation/370068

Viele Grüße,
Franz-Peter
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] Nominatim oddity

[Peter Neale via Talk-GB]

Hmm.
Well, in my case, it seems to come up as "Royaume-Uni"!
I'll need to try to fix that. (presumably in my account settings...)
Regards,Peter


On Monday, 7 December 2020, 17:38:49 GMT, Ken Kilfedder 
 wrote:  
 
 That's the name in latin for the UK, I think.  Is it under name:la, and do you 
have your browser set to latin for some reason?

I was able to set Chrome to Latin, and your URL did indeed have "Britanniarum 
Regnum" for place:country.
But in Firefox, set to English (GB), it just displays as "United Kingdom".

I wonder how many users OSM has in Vatican City?  (Where the ATMs have a Latin 
option, IIRC)

---
https://hdyc.neis-one.org/?spiregrain
spiregrain_...@ksglp.org.uk

On Mon, 7 Dec 2020, at 5:23 PM, Mark Goodge wrote:
> This may be a dim question, and this may possibly be the wrong place to 
> ask it. But, at the risk of being both dim and out of place... Why does 
> Nominatim return "Britanniarum Regnum" as the country name for objects 
> in the UK? For example:
> 
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=21279378=place
> 
> Mark
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-GB] Lorries can't limbo

[Peter Neale via Talk-GB]

Hi Ed,
Yes, that looks like it.
Many thanks for finding it for me; I've been a bit busy in the last few days.
Peter

Sent from Yahoo Mail on Android 
 
  On Fri, 13 Nov 2020 at 17:44, Ed Loach wrote:   
#yiv7977330760 #yiv7977330760 -- _filtered {} _filtered {} _filtered 
{}#yiv7977330760 #yiv7977330760 p.yiv7977330760MsoNormal, #yiv7977330760 
li.yiv7977330760MsoNormal, #yiv7977330760 div.yiv7977330760MsoNormal 
{margin:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv7977330760 a:link, 
#yiv7977330760 span.yiv7977330760MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv7977330760 
span.yiv7977330760EmailStyle19 
{font-family:sans-serif;color:windowtext;}#yiv7977330760 
.yiv7977330760MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv7977330760 
div.yiv7977330760WordSection1 {}#yiv7977330760 
The one mentioned on this list in July 2017 perhaps?

https://lists.openstreetmap.org/pipermail/talk-gb/2017-July/020359.html

  

Ed

  

From: Peter Neale via Talk-GB 
Sent: 13 November 2020 08:37
To: n...@ijive.co.uk; Jez Nicholson 
Cc: Talk-GB 
Subject: Re: [Talk-GB] Lorries can't limbo

  

I am pretty sure that I remember checking bridges in my area some time ago, 
using a tool that someone kindly provided, which flagged up all bridges, where 
the clearance height was not specified in OSM.

  

I regret that I cannot now find the link.   

  

Regards,

Peter

  

  

On Friday, 13 November 2020, 08:26:48 GMT, Jez Nicholson 
 wrote: 

  

  

Added to the Quarterly Project list 
https://wiki.openstreetmap.org/wiki/Talk:UK_Quarterly_Project#Bridge_Heights

  

On Thu, Nov 12, 2020 at 11:56 PM Neil Matthews  
wrote:


https://www.newcivilengineer.com/latest/network-rail-reveals-most-bashed-bridge-in-britain-09-11-2020/

Saw this and thought it might suit a small virtual project - to 
check/add bridge heights from mapillary images or similar might be useful.

And maybe network rail have a longer list / more info?

Cheers,
Neil



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


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

Re: [Talk-GB] Lorries can't limbo

[Peter Neale via Talk-GB]

I am pretty sure that I remember checking bridges in my area some time ago, 
using a tool that someone kindly provided, which flagged up all bridges, where 
the clearance height was not specified in OSM.
I regret that I cannot now find the link.   
Regards,Peter 

On Friday, 13 November 2020, 08:26:48 GMT, Jez Nicholson 
 wrote:  
 
 Added to the Quarterly Project list 
https://wiki.openstreetmap.org/wiki/Talk:UK_Quarterly_Project#Bridge_Heights
On Thu, Nov 12, 2020 at 11:56 PM Neil Matthews  
wrote:

https://www.newcivilengineer.com/latest/network-rail-reveals-most-bashed-bridge-in-britain-09-11-2020/

Saw this and thought it might suit a small virtual project - to 
check/add bridge heights from mapillary images or similar might be useful.

And maybe network rail have a longer list / more info?

Cheers,
Neil



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

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

Re: [talk-au] OpenStreetMap Wiki page Australian Tagging Guidelines has been changed by 2hu4u

[Peter leGras]

Hello, 2hu4u here (this is my first message on the mailing list).
Regarding water towers, not sure if there is local/state variation, but
large public tanks connected to the mains utility (commonly with capacities
of 1-25 megalitres) are referred to by Sydney Water as "covered
reservoirs". This is a grey area I guess; I thought perhaps it would be
useful to distinguish the slight nuance between designated reservoirs and
"man_made=storage_tank + content=water" of the kind that collects or stores
water on a smaller scale and is disconnected from the greater water
network. I will be posting photos of example tanks on the wiki soon.
Looking forward to working with you all.
Cheers
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-dk] Redningsskilte?

[Peter Leth]

Kære alle

Niels Elgaard nævner her i den sidste mail at der er en høring, som OSM-dk
godt kigge give et par ord med på vejen.
Det samme gælder mange andre åbne projekter. Så jeg kan kun sige at det vil
være skønt, hvis vi kan sætte et stærkt fælles svar op til det videre
politiske arbejde.

Jeg håber at det er en situation som denne, at foreningen OpenDenmark netop
derfor må kunne bruges, og jeg har derfor lavet dette dokument
https://docs.google.com/document/d/1xeY3ZfbUFykBUlOikNFp2EiTUZBbyH9BnVkztSmQJ1k/edit?usp=sharing

hvor jeg har åbnet for kommentering uden login.

Jeg ved ikke om der er en bedre form, men jeg foreslår blot at hvis der er
nogen af jer, der har kræfter, ord og interesse i at hjælpe med et
høringssvar, så kan jeg tilføje jer med redigeringsret, sådan at alle kan
kommentere og redigere det man ønsker og har mulighed for.

Jeg kan ikke forestille mig at jeg eller foreningen OpenDenmark alene kan
levere et høringssvar, men jeg tror godt vi kan sammen.

Spørgsmål - kommentarer etc kan selvfølgelig køre her, men I er også
velkommen til at kontakte mig direkte på peterlet...@gmail.com eller
telefon 51522387

I må meget gerne sende denne invitation til hvem I mener har et par
guldkorn eller fakta at bidrage med.

Tak

Med venlig hilsen
Peter Leth
Her i skikkelse af formand for foreningen OpenDenmark

Den tor. 8. okt. 2020 kl. 18.14 skrev Niels Elgaard Larsen :

> Niels Elgaard Larsen:
> > Ja, det var da en god ide.
> >
>
>  >==
>  >Ved brug af data fra Redningsnummer.dk accepterer du at opdatere data
>  >jævnligt og dermed holde de data du viser omverdenen ajour.
>  >==
>
> Apropos den slags underlige betingelser så er loven til implementering af
> Åbne Data
> direktivet i høring nu (frist 27/10)
> https://hoeringsportalen.dk/Hearing/Details/64364
>
>
> OSM-dk kunne godt slå et slag for at rydde ud i den slags betingeler, der
> er
> problemfri for kommercielle projekter, der kan kontrollere alle led i
> distributionen
> af data, men problematisk for projekter som OSM, der viderebearbejder
> data, der så
> bruges af andre, og som ikke selv udvikler brugergrænsefladerne.
>
>
>
> --
> Niels Elgaard Larsen
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>


-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-GB] National Cycle Network removal/reclassification

[Peter Neale via Talk-GB]

Hi @Ed,
What area is this, please?
NCN 51 comes near me through Milton Keynes, so I have made some adjustments to 
the relation in the past (when it was re-routed to avoid going through the 
middle of the intu shopping centre). 

Regards,Peter 

On Friday, 14 August 2020, 09:04:51 BST, Ed Loach  
wrote:  
 
 DaveF replied to:

> > So even if Sustrans declassify it, if the signs are still up shouldn’t
> > it remain in OSM?

with:
 
> OSM should be using the most up to date data available. In this
> instance
> I think Sustrans saying they've decommissioned a few NCNs &
> publishing
> an updated map is the more accurate information. I don't think the
> relations should be deleted as they're probably to be reclassified (I
> think).

In some cases OSM *is* the most up to date data there is. Locally I watched as 
the local Sustrans ranger (I hope I've got the term correct) added NCN 150 to 
the map after getting home from putting up the stickers - the relation grew 
over the few days it took. I will be leaving the local part of the NCN 51 
relation that has been reclassified for him to update as and when it gets 
re-stickered.

Ed


___
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-dk] Er I klar til at sætte dansk deltagerrekord i morgen?

[Peter Leth]

Hej Søren

Jeg har solgt ideen om is og osm til sønnik. Så vi er pt to der deltager:
Do Osm 1 og peterleth

Mobilepay 51522387 ( bare for den ene)

God dag

/ Peter

lør. 8. aug. 2020 kl. 17.16 skrev Soren Johannessen <
soren.johannes...@gmail.com>:

> Hej alle sammen
>
> Så går det løs i morgen søndag 9/8 og er I klar og fit for fight? Det
> er dagen hvor vi i OpenStreetMap vil forsøge at slå rekorden fra 2012
> med over 44 daglige deltagere. Derudover så fejrer vi OpenStreetMaps
> 16 års fødselsdag. Så hop ind i morgen og kortlæg et eller andet i
> Danmark. Om du bruger 5 min eller flere timer i morgen er ligemeget,
> det er antallet af forskellige OSM brugere vi går efter.
>
> DMI lover også hedebølge i morgen, så der er stadigvæk mulighed for at
> få  50 kr til en is eller andet køligt. Septima er sponsor med 2000
> kr, OpenDenmark foreningen med 500 kr og mit eget firma med 500 kr.
>
> Så vi har 60 personer som kan få lidt forplejning til ovenstående
> event. Så hold jer endelig ikke tilbage med at skrive til
> soren.johannessen Snabel a  gmail.com med dit Mobilpay nummer samt OSM
> brugernavn, og jeg vil overføre pengene, så hurtigt som muligt. Først
> til mølle princip.
>
> Har du ingen Mobilpay, så skriv banknummer med regnr. og kontonummer
> og jeg kan også overføre penge ad den vej til jer.
>
> Spreder du billeder, videoer eller tekst via sociale medier om
> ovenstående event, så brug hashtag #osmdkrekord
>
> I kan se hvad der er skrevet på Twitter indtil videre med dette hashtag
> https://twitter.com/search?q=osmdkrekord=typed_query=live
>
> Velmødt der ude i cyberspace og ha en god OSM kortlægnings søndag.
>
> Med venlig hilsen
> Søren Johannessen
>
> NB vores nordiske naboer dags rekorder er hhv,  Finland  84, Sverige
> 71 og Norge med 55, så dem kan vi også om vi kan slå.
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-GB] UPRN tag proposal page

[Peter Neale via Talk-GB]

Excellent proposal. No problems that I can see.
Peter 

   >On Tuesday, 21 July 2020, 09:18:02 BST, Tony OSM  
wrote:  
 
  
>Thanks for the effort.
 
>No problem to vote for this, no "red flags" for me.
 
>Tony
 
 >>On 20/07/2020 22:11, Rob Nickerson wrote:
  
 
   >>Hi all, 
  >>As discussed at the State of the Map online workshop, I took away an action 
to draft a proposal page for ref:GB:uprn. This page is now >>up online. 
  >>https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn 
  >>This is the first one of these I have done in a long time so hopefully I 
got it right. 
  >>At this stage, please highlight any "red flags" that would prevent us from 
moving to the voting stage. Feel free to also edit the page >>directly, however 
I'm of the view that less is more in this case as it keeps it short for people 
to read and also reduces the chance that  >>something is added that others do 
not agree with (which would be bad during the voting stage). 
  >>If there are no red flags I will move for a vote. 
  >>P.S. My thanks to Nick for drafting the initial text. >>P.P.S If anyone 
wants to start a page for USRN, please feel free to, otherwise I will attempt 
this later in the week.
  
  >>Best regards,
  >>Rob
 Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Q3 2020 Quarterly project Cycle Infrastructure

[Peter Neale via Talk-GB]

>On Tue, 14 Jul 2020 at 22:07, ael

> wrote:  >On Tue, Jul 14, 2020 at 09:30:00PM >+0100, 
>Adam Snape wrote:
>> 
>> this point if we're actually advocating the hitherto undocumented  usage of
>> segregated=yes to mean 'cycleway is separate from main carriageway' because
>> I suspect I'm not the only one whose been using it as per the wiki to show
>> where bicycles and pedestrians have their own designated lanes within a
>> shared use cycleway. We can't use both.

>+1  (separate lanes for cycles & pedestrians)
+1 for "segregated" referring to separate (or not) pedestrian and cycle lanes 
in a shared cycleway

Sent from Yahoo Mail on Android
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
On Tue, Jul 14, 2020 at 09:30:00PM +0100, Adam Snape wrote:
> 
> this point if we're actually advocating the hitherto undocumented  usage of
> segregated=yes to mean 'cycleway is separate from main carriageway' because
> I suspect I'm not the only one whose been using it as per the wiki to show
> where bicycles and pedestrians have their own designated lanes within a
> shared use cycleway. We can't use both.

+1  (separate lanes for cycles & pedestrians)


___
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] UPRN Locations Map

[Peter Neale via Talk-GB]

Hi Nick,
Thanks for that.
I regret that my VBA and Python are about as good as my Swahili and Martian.  
(i.e. NOT)
Many years ago, I did a bit (sic) of coding in Basic, Fortran and Algol (look 
them up in the history books) and I used Prolog for my AI project in 1984, but 
since then, I've been gradually relegated to management.
However, I am sure that there are others in this community, who will be much 
better placed than I am to use the code that you  have so kindly provided.
Regards,Peter


On Thursday, 2 July 2020, 23:19:06 BST, Nick  wrote:  
 
  
Hi Peter
 
re: "I am still not clear how best to use the data available" - I have written 
a simple bit of VBA that enables address data to be retrieved for a given UPRN 
(I attach the VBA used in a form for Excel) - this only works for Scotland but 
may be available elsewhere. Using the concept you can use Python (a friend has 
done some preliminary work) or similar. This is not elegant but is perhaps a 
first step in enabling a whole lot of development?
 
 
Cheers
 
Nick
 

 
 On 02/07/2020 18:38, Peter Neale via Talk-GB wrote:
  
 
  Hi Robert, 
  Many thanks for producing that map. 
  I was able to look at my street and see a blue pin in each of the building 
outlines that I had mapped from aerial imagery, so that gave me a warm, smug 
feeling :) 
  I too noticed some not-yet-there properties in a nearby development that had 
UPRNs assigned - Not a problem really (IMHO).  There is also one allocated to a 
pond near me; I didn't know that was "addressable"!
  
  However, I am still not clear how best to use the data available, if you 
can't use it to look up the address of the property.  Similarly, I am not sure 
how a data consumer could use the data, if we laboriously edited every property 
in OSM to include a "ref:GB:UPRN=" tag (or similar; other tags are 
available.). 
  Sorry not to be able to contribute something more useful... :( 
Regards, Peter 
 
  
  On Thursday, 2 July 2020, 17:40:51 BST, Robert Whittaker (OSM lists) 
 wrote:  
  
   I'm not completely sure if/how we can best make use of the new OS
  OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
  first step I've set up a quick slippy map with the UPRN locations
  shown:
  
  https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the data)
  
  The UPRN dataset literally just contains the UPRN number and its
  coordinates (both OS National Grid and WGS lat/lon). There are some
  additional linking datasets that link these ids to other ids (e.g.
  USRNs, TOIDs). But no address information is available directly. (You
  may be able to get street names by matching to OS Open Roads via TOIDs
  though. Coupled with Code-Point Open, you might be able to assign
  quite a few postcodes in cases where there's only one unit for a whole
  street.)
  
  The UPRN data has already helped me find a mapping error I made
  locally though -- it looks like I'd accidentally missed drawing a
  house outline from aerial imagery, and also classified a large garage
  a few doors down as a house. The two errors cancelled out when the
  houses were numbered sequentially, so I didn't notice until now. Today
  though I spotted a UPRN marker over some blank space on the map, and
  no marker over the mapped house that's probably a garage.
  
  Now a few initial thoughts on the data that I've explored so far:
  
  I believe that the UPRNs are assigned by local authorities, so
  conventions may vary from place to place. I don't know who actually
  assigns the coordinates (authority or OS). Looking at those for rows
  of houses around me, they don't seem to have been automatically given
  coordinates from the house footprint, it looks more like someone
  manually clicking on a map.
  
  The UPRN dataset should include all addressable properties. It is also
  ahead of reality in some places, as it includes locations for houses
  on a new development near me that have yet to be built yet. For blocks
  of apartments/flats, the UPRN nodes may all have the same coordinates
  or may be displaced from each other, possibly in an artificial manner.
  
  Other objects also appear to have UPRNs. Likely things I've noticed so
  far include: car parks, post boxes, telephone boxes (even after
  they've been removed), electricity sub-stations, roads and recorded
  footpaths (the UPRN locations seem to be at one end of the street, so
  usually lie at a junction), recreation grounds / play areas,
  floodlight poles (around sports pitches), and allotments. There's no
  information about the object type in the UPRN data unfortunately.
  
  Anyway, I hope some of this is useful / interesting. I hope to be on
  the OSMUK call on Saturday to discuss things further. Best wishes,
  
  Robert.
  
  -- 
  Robert Whittaker
  https://osm.mathmos.net/
  
  ___
  Talk-GB mailing list
  Talk-GB@openstreetmap.org
  https://li

Re: [Talk-GB] UPRN Locations Map

[Peter Neale via Talk-GB]

Hi Robert,
Many thanks for producing that map.
I was able to look at my street and see a blue pin in each of the building 
outlines that I had mapped from aerial imagery, so that gave me a warm, smug 
feeling :)
I too noticed some not-yet-there properties in a nearby development that had 
UPRNs assigned - Not a problem really (IMHO).  There is also one allocated to a 
pond near me; I didn't know that was "addressable"!

However, I am still not clear how best to use the data available, if you can't 
use it to look up the address of the property.  Similarly, I am not sure how a 
data consumer could use the data, if we laboriously edited every property in 
OSM to include a "ref:GB:UPRN=" tag (or similar; other tags are available.).
Sorry not to be able to contribute something more useful... :(
Regards,Peter
 

On Thursday, 2 July 2020, 17:40:51 BST, Robert Whittaker (OSM lists) 
 wrote:  
 
 I'm not completely sure if/how we can best make use of the new OS
OpenData (UPRNs, USRNs and related links) in OpenStreetMap, but as a
first step I've set up a quick slippy map with the UPRN locations
shown:

https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show the data)

The UPRN dataset literally just contains the UPRN number and its
coordinates (both OS National Grid and WGS lat/lon). There are some
additional linking datasets that link these ids to other ids (e.g.
USRNs, TOIDs). But no address information is available directly. (You
may be able to get street names by matching to OS Open Roads via TOIDs
though. Coupled with Code-Point Open, you might be able to assign
quite a few postcodes in cases where there's only one unit for a whole
street.)

The UPRN data has already helped me find a mapping error I made
locally though -- it looks like I'd accidentally missed drawing a
house outline from aerial imagery, and also classified a large garage
a few doors down as a house. The two errors cancelled out when the
houses were numbered sequentially, so I didn't notice until now. Today
though I spotted a UPRN marker over some blank space on the map, and
no marker over the mapped house that's probably a garage.

Now a few initial thoughts on the data that I've explored so far:

I believe that the UPRNs are assigned by local authorities, so
conventions may vary from place to place. I don't know who actually
assigns the coordinates (authority or OS). Looking at those for rows
of houses around me, they don't seem to have been automatically given
coordinates from the house footprint, it looks more like someone
manually clicking on a map.

The UPRN dataset should include all addressable properties. It is also
ahead of reality in some places, as it includes locations for houses
on a new development near me that have yet to be built yet. For blocks
of apartments/flats, the UPRN nodes may all have the same coordinates
or may be displaced from each other, possibly in an artificial manner.

Other objects also appear to have UPRNs. Likely things I've noticed so
far include: car parks, post boxes, telephone boxes (even after
they've been removed), electricity sub-stations, roads and recorded
footpaths (the UPRN locations seem to be at one end of the street, so
usually lie at a junction), recreation grounds / play areas,
floodlight poles (around sports pitches), and allotments. There's no
information about the object type in the UPRN data unfortunately.

Anyway, I hope some of this is useful / interesting. I hope to be on
the OSMUK call on Saturday to discuss things further. Best wishes,

Robert.

-- 
Robert Whittaker
https://osm.mathmos.net/

___
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-dk] Ukrediteret brug af OSM data, endda mod betaling.

[Peter Leth]

Kære alle

Som jeg skrev i aftes, så har jeg ringet til Mette i dag og snakket med
hende (ud fra betragtningen om at det måske nogle gange kan være rart nok
at kunne snakke sammen om en sag sådan lidt mere uformelt)

Hun giver udtryk for at hun ikke ønsker at gøre noget forkert, og at hun
har ladet sig inspirere af Mapiful (dem i Stockholm, som jeg nævnte i går,
og som jeg virkelig heller ikke kan se nogen kreditering af osm på) og at
det derfor også overraskede hende at der skulle være noget galt.

Jeg foreslog hende at hun kunne skrive til Anders Hedelund at hun ville
kigge på sagen, sådan at vi andre i osm-fællesskabet, via Anders, kunne
blive orienteret, og at hun i den mail kunne give udtryk for at hun havde
fået vores henvendelse og hvad hun ville gøre ud fra vores henvendelse. Og
så foreslog jeg hende at hun også fulgte op med emails til os, når hun
havde gjort noget i forbindelse med vores henvendelse.

Jeg har tilbudt at hun kan ringe, hvis hun vil.
Jeg har både indledningsvis og til sidst understreget at jeg ikke taler på
nogens fælles vegne.

Men blot til orientering om at der er en dialog i gang.

Hilsen
Peter Leth



Den man. 8. jun. 2020 kl. 11.04 skrev :

> Firmaets hjemmeside, nederst: http://mkayart.dk/handelsbetingelser/
> "Plakaterne følger retningslinjerne for OpenStreetMap.com".
>
>
> --
>
>
> > Sent: Sunday, June 07, 2020 at 5:46 PM
> > From: "Anders Wegge Keller" 
> > To: "OpenStreetMap Denmark" 
> > Subject: [Talk-dk] Ukrediteret brug af OSM data, endda mod betaling.
> >
> > Er der nogen af jer der har kendskab til firmaet bag denne og mange andre
> > plakater?
> >
> >
> http://mkayart.dk/shop/11-hjemstavn-kollektionen/304-aarup-begraenset-antal---max-75-stk/
> >
> > Det pikerer mig lidt at man laver et kommercielt produkt uden
> overhovedet at
> > nævne hvor data kommer fra.
> >
> > --
> >
> > //Wegge
> >
> > ___
> > Talk-dk mailing list
> > Talk-dk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-dk
> >
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>


-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Ukrediteret brug af OSM data, endda mod betaling.

[Peter Leth]

Hej alle
Jeg så indslaget her
https://www.tvmidtvest.dk/struer/mette-kirstine-saelger-plakater-til-stolte-lokale-i-smaa-byer

Dengang troede jeg at hun bare hapsede fra google og tænkte at hun burde
lave sin forretning på osm

Jeg tænker at jeg kunne prøve at tage en snak med hende i morgen, så hun fx
lige fik lidt hjælp til det med kreditering og ophavsret. Og så vil jeg
selvfølgelig gerne indskyde at det også kan skuffe mig hvis hun ikke har
givet spørgsmålet om ophavsret større opmærksomhed end det lyder til.

Som et ps skal vi lige have kig på et firma i Stockholm der ser ud til at
lave det samme nummer. Har glemt navnet men så deres kort og tænkte at det
lignede osm uden navn.

/ Peter

søn. 7. jun. 2020 kl. 18.08 skrev Anders Wegge Keller :

> På Sun, 7 Jun 2020 17:57:46 +0200
> Flemming Bruun  skrev:
>
>  Der er også adresse på hjemmesiden, så det var ikke så meget en adresse
> jeg
> var ude efter. Det var mere om der var nogen der har set problemstillingen
> tidligere.
>
> > _DK-Hostmaster har disse data__
> > _
> > *Navn*Mkay Art
> > *Adresse* Smedegade 2, 2. th.
> > *Postnr. og by*   7600 Struer
> > *Land*Danmark
> > *Telefonnr.*  -
> >
> >
> > _Virk.dk har disse data:__
> > _
> > CVR-nummer
> > 40318003
> > Adresse
> > Smedegade 2, 2. th.
> > Postnummer og by
> > 7600 Struer
> > Startdato
> > 25.02.2019
> > Virksomhedsform
> > Enkeltmandsvirksomhed
> >
> > Mailmkay...@hotmail.com
> > KommuneStruer
> > Branchekode900300 Kunstnerisk skaben
> >
> > _Fuldt ansvarlig deltager_
> > Mette Kirstine Hansen
> > Smedegade 2, 2. th.
> > 7600 Struer
> > Danmark
> >
> >
> >
> >
> > Den 07-06-2020 kl. 17:46 skrev Anders Wegge Keller:
> > > Er der nogen af jer der har kendskab til firmaet bag denne og mange
> andre
> > > plakater?
> > >
> > >
> http://mkayart.dk/shop/11-hjemstavn-kollektionen/304-aarup-begraenset-antal---max-75-stk/
> > >
> > > Det pikerer mig lidt at man laver et kommercielt produkt uden
> > > overhovedet at nævne hvor data kommer fra.
> > >
> >
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[OSM-talk] W3C - OGC Joint Online Workshop on Web Maps - September 21st - October 2nd 2020

[Rushforth, Peter (NRCAN/RNCAN) via talk]

Hello,



I apologize for emailing you directly, possibly duplicating communications that 
you may have already received.



I would like to draw your attention to the recently re-opened call for 
positions or presentations for a joint W3C - OGC online workshop on 
standardizing maps for the Web<https://w3.org/2020/maps/>, to be held during 
the weeks of Sept 21st through October 2nd 2020.



In light of current circumstances, we've redesigned the structure of the 
workshop to optimize for remote, global participation. Instead of a few days of 
tightly scheduled sessions, we are planning to distribute the video-conference 
presentations over two weeks, in late September 2020, with written discussion 
to continue through October, so that everyone has a chance to catch up & 
comment on the discussion topics.



The goal of the workshop series is to start a conversation between web map 
creators, geospatial experts, and web standards editors and web browser 
developers, about how standardization can improve web mapping, for creators and 
for end users.



While the range of topics that can be addressed by participants is very broad, 
we are requesting presentations that specifically relate their content to the 
central topic of Web map standardization, such as accessibility, 
internationalization, discovery, privacy, security, extensibility etc.



We also want to continue with the original plan to have "hack" sessions, where 
community members can welcome new contributors to their open-source projects. 
The full details are still being worked out, and feedback or suggestions are 
welcome.



The deadline for proposals is June 30th, so that we have plenty of time to 
arrange a full agenda before September.  It would also be helpful, if you are 
interested, if you could fill in the registration 
form<https://www.w3.org/2002/09/wbs/1/maps2020/> sooner rather than later, so 
that we know who is interested, and what you're interested in.



Please, share the news about the workshop within your organizations and 
communities, and with anyone else you think would be interested in improving 
maps on the web.



Please feel free to contact me directly, or to email the program 
committee<mailto:public-maps-workshop...@w3.org?subject=W3C%20-%20OGC%20Joint%20Online%20Workshop%20on%20Web%20Maps%20-%20September%2021st%20-%20October%202nd%202020>
 with any questions you may have.



Warm regards,

Peter





Peter Rushforth

Co-Chair, Program Committee

W3C - OGC Joint Online Workshop on Web Maps



Technology Advisor

Canada Centre for Mapping and Earth Observation

Natural Resources Canada / Government of Canada

peter.rushforth.nrcan-rn...@gccollaboration.ca<mailto:peter.rushforth.nrcan-rn...@gccollaboration.ca>
 / Tel: 613-759-7915



Conseiller technique

Centre canadien de cartographie et d'observation de la Terre

Ressources naturelles Canada / Gouvernement du Canada

peter.rushforth.nrcan-rn...@gccollaboration.ca<mailto:peter.rushforth.nrcan-rn...@gccollaboration.ca>
 / Tél: 613-759-7915




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

Re: [Talk-GB] Can anyone reverse this changeset please?

[Peter Neale via Talk-GB]

Sorry if I did not make myself clear enough.  (Every day is a new learning 
opportunity!)

At least it's good to know that I have not broken the system :-)

Regards,Peter 

On Monday, 27 April 2020, 11:24:14 BST, Andy Townsend  
wrote:  
 
  On 27/04/2020 11:16, Peter Neale wrote:
  
 
  It seems that we have had 2 of us attempting the same change at the same 
time. 

 
 
Generally speaking, IRC's better for this sort of request as everyone sees 
what's happening in real time
 
 
   I hope that the database change  control can cope with this. 

 
It can - multiple deletion requests will just be ignored
 
 
> I did try to avoid such a clash by responding here before starting work.
 
I've clearly been working with people from the Netherlands and Germany too long 
:)  - I didn't interpret "I think that I understand the issue ... A solution 
may be ... I am happy to spend a while trying this" as "I'm doing it NOW".
 
Best Regards,
 
Andy
 

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

Re: [Talk-GB] Can anyone reverse this changeset please?

[Peter Neale via Talk-GB]

Noted.  I have been careful to separate the ways sharing points and only delete 
the way in question.
Regards,Peter
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb 

On Monday, 27 April 2020, 10:56:40 BST, Jez Nicholson 
 wrote:  
 
 Note that the vast majority of the points in the Way were pre-existing. Any 
fix should leave them in place.
On Mon, Apr 27, 2020 at 10:54 AM nathan case  wrote:


I’m fairly sure Potlach (assuming you want to tackle this via a browser editor) 
allows you to delete larger areas in one go – rather than deleting point by 
point.

 

Cheers.

 

From: Peter Neale via Talk-GB 
Sent: Monday, April 27, 2020 10:43 AM
To: Talk-GB ; Jez Nicholson 
Subject: Re: [Talk-GB] Can anyone reverse this changeset please?

 

I think that I understand the issue.  A solution may be to delete individual 
points until the whole way is small enough to be shown on a screen at editable 
zoom.  

 

I am happy to spend a while trying this, but it is probably best if only one of 
us is stirring the pot at once.

 

Regards,

Peter

 

 

 

On Monday, 27 April 2020, 10:32:44 BST, Jez Nicholson  
wrote:

 

 

A new user has created a new way in Brighton to indicate the Hollingbury 
residential error https://www.openstreetmap.org/way/785162533 They freely admit 
their error but are unable to remove it, as am I. Would anyone be able to 
assist please?

 

I only have anecdotal evidence (like this one) but it seems that a 'new user 
thing to do' is to 'correct my local area'. Might be another reason to lock 
boundaries from new user changes?

___
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] Can anyone reverse this changeset please?

[Peter Neale via Talk-GB]

It seems that we have had 2 of us attempting the same change at the same time.  
I hope that the database change  control can cope with this.
I did try to avoid such a clash by responding here before starting work.

Regards,Peter


On Monday, 27 April 2020, 11:12:59 BST, Andy Townsend  
wrote:  
 
  On 27/04/2020 10:56, Jez Nicholson wrote:
  
 
Note that the vast majority of the points in the Way were pre-existing. Any fix 
should leave them in place. 
  On Mon, Apr 27, 2020 at 10:54 AM nathan case  wrote:
  
   
I’m fairly sure Potlach (assuming you want to tackle this via a browser editor) 
allows you to delete larger areas in one go – rather than deleting point by 
point.
 
   
  
I believe I've resolved this in 
https://www.openstreetmap.org/changeset/84189877 - please let us know if all is 
OK.
 
 
For completeness, that was done in JOSM using the reverter plugin.  It also 
deleted the three extra nodes added in 
https://www.openstreetmap.org/changeset/82728827 .
 
Potlatch 2 would also have worked, but I'd have needed to delete the 3 new 
nodes separately.
 
Some combination of  "revert.pl" "undo.pl" and/or "delete.pl" in the OSM revert 
scripts https://wiki.openstreetmap.org/wiki/Revert_scripts would have worked, 
but I'd have needed to explicitly say "yes please delete the new way and the 3 
new nodes".
 
Best Regards,
 
Andy
 

 
 ___
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] Can anyone reverse this changeset please?

[Peter Neale via Talk-GB]

I THINK I have done it.  
It took a bit of fiddling to separate some shared points, but then I was able 
to cut the offending line and delete a section at a time (which fitted on the 
screen).
I hope that I have not disturbed anything else in the process.  
Regards,Peter
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb 

On Monday, 27 April 2020, 10:44:26 BST, Peter Neale via Talk-GB 
 wrote:  
 
 I think that I understand the issue.  A solution may be to delete individual 
points until the whole way is small enough to be shown on a screen at editable 
zoom.  
I am happy to spend a while trying this, but it is probably best if only one of 
us is stirring the pot at once.
Regards,Peter


On Monday, 27 April 2020, 10:32:44 BST, Jez Nicholson 
 wrote:  
 
 A new user has created a new way in Brighton to indicate the Hollingbury 
residential error https://www.openstreetmap.org/way/785162533 They freely admit 
their error but are unable to remove it, as am I. Would anyone be able to 
assist please?
I only have anecdotal evidence (like this one) but it seems that a 'new user 
thing to do' is to 'correct my local area'. Might be another reason to lock 
boundaries from new user changes?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Can anyone reverse this changeset please?

[Peter Neale via Talk-GB]

I think that I understand the issue.  A solution may be to delete individual 
points until the whole way is small enough to be shown on a screen at editable 
zoom.  
I am happy to spend a while trying this, but it is probably best if only one of 
us is stirring the pot at once.
Regards,Peter


On Monday, 27 April 2020, 10:32:44 BST, Jez Nicholson 
 wrote:  
 
 A new user has created a new way in Brighton to indicate the Hollingbury 
residential error https://www.openstreetmap.org/way/785162533 They freely admit 
their error but are unable to remove it, as am I. Would anyone be able to 
assist please?
I only have anecdotal evidence (like this one) but it seems that a 'new user 
thing to do' is to 'correct my local area'. Might be another reason to lock 
boundaries from new user changes?___
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] underfoot art

[Peter Neale via Talk-GB]

There may also be merit in tagging a location that is frequently / consistently 
used for more ephemeral art.  Any time you visit, you can reasonably expect to 
see something, but it might be a different thing from what was there yesterday.
Regards,Peter
On Monday, 27 April 2020, 10:07:37 BST, Edward Catmur 
 wrote:  
 
 
These things can be permanent – mosaic or other types of inlay.

  

From: Mike Parfitt
Sent: 27 April 2020 08:56
To: mar...@templot.com; neal...@yahoo.co.uk; talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] underfoot art

  

There may be some merit in tagging permanent artwork on the sides of buildings.

But tagging pavement/street art that will vanish after a couple of showers 
seems pointless. 



From: Peter Neale via Talk-GB 
Sent: 26 April 2020 18:38:06
To: mar...@templot.com 
Cc: Talk-gb OSM List 
Subject: Re: [Talk-GB] underfoot art 

 

Pavement art, or perhaps street painting? 

  

  

Street painting - Wikipedia 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Street painting - Wikipedia
 |  |

 |

 |


  

  

Regards,

Peter

  

Sent from Yahoo Mail on Android

  


On Sun, 26 Apr 2020 at 15:32, Martin Wynne

 wrote:

What is this stuff called?

  

  https://goo.gl/maps/uVVfLbicFhT25TM5A

  

  https://goo.gl/maps/5g1yJnsAGEHzpqqY6

  

I got as far as tourism=artwork but then

  

  artwork_type= ?

  

thanks,

  

Martin.

  

___

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] underfoot art

[Peter Neale via Talk-GB]

Pavement art, or perhaps street painting?

Street painting - Wikipedia  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Street painting - Wikipedia
 

  |   |

  |

  |

  

Regards,Peter

Sent from Yahoo Mail on Android 
 
  On Sun, 26 Apr 2020 at 15:32, Martin Wynne wrote:   What 
is this stuff called?

  https://goo.gl/maps/uVVfLbicFhT25TM5A

  https://goo.gl/maps/5g1yJnsAGEHzpqqY6

I got as far as tourism=artwork but then

  artwork_type= ?

thanks,

Martin.

___
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] Q2 2020 Quarterly project GP Surgeries and health sites

[Peter Neale via Talk-GB]

Thanks for pointing out how to import and convert the file.  After a bit of 
trial and error, I discovered how to get Excel to use the "¬" as the delimiter 
and (as you said), the addresses are quite inconsistent, but the data all lines 
up again in the Post Code Column.  There are some further issues in the 
ParentName Column, with the County sometimes duplicated there and sometimes 
there instead of the County Column. 
Thank you for taking me a step forward in my "How to Use Excel" course!
Regards,Peter

On Thursday, 16 April 2020, 13:52:06 BST, Robert Whittaker (OSM lists) 
 wrote:  
 
 On Thu, 16 Apr 2020 at 12:27, Peter Neale  wrote:
> I tried following the link to your proposed new source of “official” data, 
> but none of the 3 links to the data worked very well for me.
>
> Link 1:  (API format) led to http 404 error.
> Link 2  (CSV(TSV) format – led to http 404 error
> Link 3  (XSV format) downloaded a file with a “.csv” file extension that 
> seemed to be tab-separated, rather than comma-separated.  I took that into a 
> text editor and did a global Find and Replace of Tab with Comma.  The 
> resultant .csv file loaded into Excel just fine, but it has over 11,000 lines 
> and many of them must now have additional commas, because a number of fields 
> are right-shifted (Post Code in the Latitude Column, Latitude in the 
> Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, 
> with the whole address in Address 2, Address 3, etc.  Then quite a few (from 
> my sample in the first 30) have County values in the ParentName Field.  So I 
> fear that, unless you can do a better conversion than I did (and you almost 
> certainly could, I know!) you will have a lot of manual cleaning up to do, 
> before you can use this data.

Yes, the first two links at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
are broken for me as well. For the third link, it looks like they
tried to do CSV, but didn't understand how to escape commas within the
fields, and so opted to use a different character "¬" instead. If you
import this into a spreadsheet, and tell it to use just "¬" as the
column separator, I think it works out fine, with all the entries in
the right place. (You can certainly do this with LibreOffice; I'm not
sure about Excel.) The address lines seem to be used inconsistently,
but everything is back aligned when you get to the postcode field.

Best wishes,

Robert.

-- 
Robert Whittaker

___
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] Q2 2020 Quarterly project GP Surgeries and health sites

[Peter Neale via Talk-GB]

"Anyone?"  Huh?  (seems to be lacking the back-story!)
Regards,Peter

On Thursday, 16 April 2020, 15:16:45 BST, Andy Mabbett 
 wrote:  
 
 Anyone?

___
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] Q2 2020 Quarterly project GP Surgeries and health sites

[Peter Neale via Talk-GB]

Hi Robert,
I also don’t want to delete the objects completely; as they do exist, so we 
should be able to map them.  
However, I do take your point that a pharmacy which is not open to the public 
is not an “amenity” in OSM.  So my 2 “wholesale” pharmacies do not meet the 
wiki definition of “amenity=pharmacy: a shop where a pharmacist sells 
medications” > “A shop is a place selling retail products or services.”
I think they may both be better tagged as “office=company” (I know that one of 
them is also the head office of the company and they both function as offices). 
 I could add a Note explaining why they are not tagged as “amenity-pharmacy”, 
which might deter other mappers from using this tagging, in response to the 
flag generated by your excellent tool.
I tried following the link to your proposed new source of “official” data, but 
none of the 3 links to the data worked very well for me.
Link 1:  (API format) led to http 404 error.Link 2  (CSV(TSV) format – led to 
http 404 errorLink 3  (XSV format) downloaded a file with a “.csv” file 
extension that seemed to be tab-separated, rather than comma-separated.  I took 
that into a text editor and did a global Find and Replace of Tab with Comma.  
The resultant .csv file loaded into Excel just fine, but it has over 11,000 
lines and many of them must now have additional commas, because a number of 
fields are right-shifted (Post Code in the Latitude Column, Latitude in the 
Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, with 
the whole address in Address 2, Address 3, etc.  Then quite a few (from my 
sample in the first 30) have County values in the ParentName Field.  So I fear 
that, unless you can do a better conversion than I did (and you almost 
certainly could, I know!) you will have a lot of manual cleaning up to do, 
before you can use this data.
The good news is that neither of my “wholesale” pharmacies is in that 
downloaded file, so, if you were able to use it as a source for your comparison 
tool, it would no longer flag them as “missing pharmacies”.
Good luck and thanks for the excellent tools, which keep me busy, trying to 
find missing post boxes, pharmacies and the like.


Regards,Peter 

On Wednesday, 15 April 2020, 16:46:43 BST, Robert Whittaker (OSM lists) 
 wrote:  
 
 On Sun, 12 Apr 2020 at 20:40, Peter Neale  wrote:
> I looked up my 2 "wholesale" pharmacies on the list.  Unfortunately, they are 
> both classed as "community", so will continue to be included in your checking 
> tool.
>
> So... ...should we:
> a.  Continue as we are: Plot them in OSM, tag them as pharmacies, but give 
> them a name that makes it clear that they are not publicly accessible?
> b.  Delete them from OSM, so that consumers don't think they are publicly 
> accessible.  (But they do exist and who knows what consumers will really want 
> to find?)  Then we could ask you to manually delete them from the checking 
> tool (but you probably won't want to keep doing that).
> c.  Do something else?

I certainly wouldn't advocate any inappropriate tagging just to keep
my tool happy! So if we don't think they should be amenity=pharmacy,
then we shouldn't tag them like that. While they may technically be
pharmacies, I would think that amenity=pharmacy is best reserved for
places that are amenities for the general public to use, which would
rule out option (a). As for (b), I wouldn't necessarily delete the
objects completely from OSM: if there's a business presence on the
ground, that could still be tagged. The question then is whether it's
worth tweaking my tool to remove these false positives. You could just
ignore the "missing pharmacy" markers local to you that you know are
wrong. As you say, I would have a manually maintained "ignore" list,
but that would be more effort for me.

What I'd prefer to to is to switch to a better data source for my
pharmacy list. There is a list of NHS-contracted pharmacies at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
which I think would closer match what we want for amenity=pharmacy,
but unfortunately that list appears to be England only. So I'd need to
find corresponding lists for Wales and Scotland. (NI isn't in the data
I'm currently using. I've found
https://www.psni.org.uk/registration/premises-registration/changes-to-the-premises-register/
but the data is all locked up in PDFs.) Can anyone help out here?

Robert.

-- 
Robert Whittaker

___
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] Q2 2020 Quarterly project GP Surgeries and health sites

[Peter Neale via Talk-GB]

Hi  Robert,
I looked up my 2 "wholesale" pharmacies on the list.  Unfortunately, they are 
both classed as "community", so will continue to be included in your checking 
tool.
So... ...should we:a.  Continue as we are: Plot them in OSM, tag them as 
pharmacies, but give them a name that makes it clear that they are not publicly 
accessible?b.  Delete them from OSM, so that consumers don't think they are 
publicly accessible.  (But they do exist and who knows what consumers will 
really want to find?)  Then we could ask you to manually delete them from the 
checking tool (but you probably won't want to keep doing that). c.  Do 
something else?
Regards,Peter 

   >On Sunday, 12 April 2020, 18:44:35 BST, Robert Whittaker (OSM lists) 
 wrote:  > > >On Sun, 12 Apr 2020 at 18:08, 
Peter Neale  wrote:
>> As Boots' stores don't ALL have a pharmacy counter, IMHO they should be 
>> tagged as "shop=chemist".  Those that DO have a >>pharmacy (dispensing 
>> prescriptions) should be additionally tagged, either with "pharmacy=yes", or 
>> with a separate node for the >>pharmacy.  I think that would fit with the 
>> checking that you describe for your tool.
>>
>Both of those will get picked up by my tool. You could also do
>shop=chemist and amenity=pharmacy together, or just amenity=pharmacy
>on it's own. The best choice will probably depend on the nature of the
>Boots branch. Some may essentially just be a pharmacy counter with a
>small range of other medicines also available. Others branches will be
>a much larger store, where the pharmacy counter is more incidental.
>
>> As regards "pharmacy type", does your data identify what I would call 
>> "wholesale pharmacies", who have no public access, but supply >>medicines to 
>> hospitals, care homes and individual customers in their homes?  I know of 2 
>> in my area.  In one case, I changed the >>name to "Jardines (on line)" 
>> (Node: 6409354480) and in the other to "Mediva Private Pharmacy" (Node: 
>> 6443190532), in an attempt to >>make it clear that there is no public access.
>> Could these be excluded in future?
>
>The data I use can be downloaded from
>https://www.pharmacyregulation.org/registers -- it's the "list of
>registered pharmacies". As of today, I'm now just keeping those with a
>Type (the last column) of either "Community" or "Temporary -
>Community/Portacabin". I think doing this corresponds most closely to
>what we'd want to tag as amenity=pharmacy in OSM. For internal
>hospital and prison pharmacies, and for internet-only pharmacies that
>you can't get prescriptions from as a walk-in customer, I don't think
>they should be tagged as amenity=pharmacy.
>
>Best wishes,>
>Robert.
>
>-- 
>Robert Whittaker

___
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] Q2 2020 Quarterly project GP Surgeries and health sites

[Peter Neale via Talk-GB]

Hi Robert,
As Boots' stores don't ALL have a pharmacy counter, IMHO they should be tagged 
as "shop=chemist".  Those that DO have a pharmacy (dispensing prescriptions) 
should be additionally tagged, either with "pharmacy=yes", or with a separate 
node for the pharmacy.  I think that would fit with the checking that you 
describe for your tool.
As regards "pharmacy type", does your data identify what I would call 
"wholesale pharmacies", who have no public access, but supply medicines to 
hospitals, care homes and individual customers in their homes?  I know of 2 in 
my area.  In one case, I changed the name to "Jardines (on line)" (Node: 
6409354480) and in the other to "Mediva Private Pharmacy" (Node: 6443190532), 
in an attempt to make it clear that there is no public access.   Could these be 
excluded in future? Regards,Peter 

On Sunday, 12 April 2020, 14:41:01 BST, Robert Whittaker (OSM lists) 
 wrote:  
 
 >On Sat, 11 Apr 2020 at 18:39, Dave Love  wrote:
>>
>> On Thu, 2020-04-09 at 12:08 +0100, SK53 wrote:
>> > Robert Whittaker has a Pharmacy QA <https://osm.mathmos.net/pharmacy/
>> > > site
>>
>> That shows a Boots missing which I tagged as the brand from the
>> correction iD wanted (brand=Boots shop=chemist).  How should Boots be
>> tagged, and does iD need a fix?  (I assume all Boots have pharmacies,
>> but maybe not.)
>
>As far as my tool at https://osm.mathmos.net/pharmacy/progress/ is
>concerned, pharmacies are recognised as OSM objects tagged with 
>either>amenity=pharmacy or pharmacy=yes*. (The latter can be used on things
>like supermarkets and doctors surgeries, when things aren't mapped in
>enough detail to have a separate amenity=pharmacy node.)
>
>As for whether all Boots stores have pharmacies, I think most do, but
>some don't: 
>https://www.boots-uk.com/about-boots-uk/about-boots/boots-in-numbers/
>says there are 2,465 Boots stores, but in the General Pharmaceutical
>Council register of Pharmacies, there are only 2304 premises
>registered to 'Boots UK Limited'.
>
>Robert
>
>PS: I've just noticed that the data I'm using for my tool now contains
>a "Pharmacy Type" field. This means I can exclude internet only
>pharmacies, temporary locations (e.g. for events) and internal
>hospital and prisons pharmacies. This will hopefully make the
>comparison shown by the tool must more useful.
>
>* Because of the change to exclude hospital and prison pharmacies from
>the GPhC data, OSM objects with pharmacy=yes will only be picked up in
>my tool if they do not also have amenity=hospital or amenity=prison
>too.

--
Robert Whittaker

___
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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Peter Neale via Talk-GB]

Hi Lester,
Sorry if my post was a bit of a rant.  I have a history of having to fight to 
get IT systems that do the hard work and preventing them demanding that people 
do the translation into "machine-speak".
Thanks for the explanation.
Regards,Peter
On Thursday, 9 April 2020, 10:29:05 BST, Lester Caine  
wrote:  
 
 On 03/04/2020 10:15, Peter Neale via Talk-GB wrote:
> So, will I have to quote a 20-digit alpha-numeric code, if I want to 
> order something from Amazon? ..or get my grandchildren to send me a 
> birthday card?
> 
> (I do not know what these UPRN's look like, but I bet they are not as 
> easy to remember as "Rose Cottage, 3 Church Lane, XX3 4ZZ")
> 
> We have to think about human readability and memorability, versus 
> machine computability and we need to be careful not to make the humans 
> do all the work, just to make it easier for the machines.  Making me use 
> a PostCode is already making me do some of the work, but at least they 
> are only 6 or 7 characters.

The NLPG is intended to provide a single database of all the land in the 
United Kingdom. Councils have been building this for many years now, and 
it allows parcels of land that the Post Office do not have any reference 
to in their Postal Address File to be uniquely identified. Looking up 
data using Postcodes can be fun but often due to people having the wrong 
postcode anyway. We can identify the vast majority of residential and 
business locations using 'building Number'/'Postcode', but additional 
data is useful to identify that this short form is actually correct, but 
your council tax or business rates will be charged against the UPRN 
reference on the council systems. It is not intended to be anything 
other than a 'machine readable' unique refference ...

-- 
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

___
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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence

[Peter Neale via Talk-GB]

So, will I have to quote a 20-digit alpha-numeric code, if I want to order 
something from Amazon? ..or get my grandchildren to send me a birthday card?
(I do not know what these UPRN's look like, but I bet they are not as easy to 
remember as "Rose Cottage, 3 Church Lane, XX3 4ZZ") 
We have to think about human readability and memorability, versus machine 
computability and we need to be careful not to make the humans do all the work, 
just to make it easier for the machines.  Making me use a PostCode is already 
making me do some of the work, but at least they are only 6 or 7 characters. 
Regards,Peter

On Friday, 3 April 2020, 09:59:27 BST, Mark Goodge  
wrote:  
 
 

On 03/04/2020 09:27, Robert Whittaker (OSM lists) wrote:

> There will presumably be a drive in government circles to store
> addresses as UPRN's, and then fetch the associated location and
> address data from AddressBase. Assuming Rob's interpretation is
> correct (I think it probably is) then this could be bad new for
> sources of addresses and postcodes for OSM. While we'll be more easily
> able to geo-locate objects from their URPN's, the actual addresses in
> any datasets will become more likely to be contaminated by OS's IP
> rights in AddressBase.

In the long run, I suspect this could actually spell the end for postal 
addresses (as distinct from geographic addresses). If every property has 
a published, unique number, analogous to a telephone number, then all 
that's necessary for, say, Amazon to deliver a package to me is for them 
to know the UPRN of my house. Their routing software will then do all 
the heavy lifting of plotting how to get the package from their depot to 
my door.

Mark

___
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] Adding Leeds Bins to OpenStreetMaps

[Peter Neale via Talk-GB]

I commend your efforts, but can I suggest a small change to your proposal?
(I am still a bit of a novice on OSM, so please feel free to tell me I am 
totally wrong)
Rather than "lcc:id=1849" should you not use, "id=lcc1849", or perhaps 
"ref=lcc1849", or even "ref:lcc=1849".
I am not sure which (if any) would be most correct, but I feel that what you 
are trying to record is a type of reference or identity, not a type of lcc.
I also note that Taginfo shows 91,800 uses of "id=*", but over 10.3 million 
uses of "ref=*", so "ref =nnn"would seem by far the most popular tag for a 
reference number. 
Also, I do not see the need to "hide" the comment as "lcc:comments="; why not 
just use "note=under city centre team management"?
As I said, please feel free to tell me I am wrong; I am engaging here as part 
of my education in OSM.
Regards,Peter
On Thursday, 26 March 2020, 10:12:56 GMT, Patrick Lake 
 wrote:
 
 
 
Hi Jez,
 
  
 
I agree, we are going to encourage them to rely on OSM as their main source of 
data in the future, but whether they’ll use it for essential stuff like 
planning collection routes I don’t know. We (ODI Leeds), however, will be 
relying on OSM data, as this is all part of a wider project we’re doing for LCC 
involving analysis on how much waste is collected from these bins and where the 
optimum location for additional litter bins and recycling points would be. So 
we’re keen for it to be accurate.
 
  
 
I thought of just tagging the LCC ID as lcc:id as I assume it will be 
meaningless to anyone not from the council. Here’s the rest of the tags we 
planned to use with examples from the data we’re importing (obviously we can 
change these):
 
amenity=waste_basket

   - waste_basket:model=”metal square twin”
   - condition=good/fair/poor
   - waste_basket:defects=loose
   - waste_basket:collection_days=mon/fri (or lcc:collection_days ?)
   - lcc:id=1849
   - lcc:comments=”under city centre team management”
 
  
 
What do you think?
 
  
 
Cheers,
 
Patrick
 
  
 
o/talk-gb

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

Re: [Talk-GB] Abusive posts

[Peter Neale via Talk-GB]

Hi Matthew,
Thanks for dealing with this.
I'm just glad that it is so rare.
Regards,Peter
On Saturday, 14 March 2020, 12:14:46 GMT, Matthew Newton 
 wrote:  
 
 Hi all,

Seen all the messages. Apologies for the delay in sorting this.

In all the years I've been monitoring this list I don't ever recall
seeing behaviour like that. It most certainly isn't acceptable. Minor
disagreements at times, sure, but outright abuse is way over the top.

He's gone.

Cheers,

Matthew



___
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] European Water Project - Introduction

[Peter Neale via Talk-GB]

Thanks Simon,
I had thought that such a tightly run and structured organisation as OSM 
would have someone moderating every mailing list 

Regards,Peter  
 

On Saturday, 14 March 2020, 08:47:49 GMT, Simon Poole  
wrote:  
 
  
Peter I don't believe there is/are any active moderators at this point. The UK 
community should nominate one or more, and ask the OWG to instate them as list 
moderators. In any case pleading to them here will not work (and likely 
wouldn't work even if there were some).
 
Simon
 
 Am 13.03.2020 um 23:37 schrieb Peter Neale via Talk-GB:
  
 
  List Moderators, 
  Please remove @Daniel Holsey from this list.  His contribution will not be 
missed. 
Regards, Peter
   ___
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] European Water Project - Introduction

[Peter Neale via Talk-GB]

List Moderators,
Please remove @Daniel Holsey from this list.  His contribution will not be 
missed.
Regards,Peter
On Friday, 13 March 2020, 21:31:57 GMT, Daniel Holsey  
wrote:  
 
 Your A Nonce Mate
On Fri, 13 Mar 2020 at 21:03, BD  wrote:

 Hi,

I quite like the idea of adding free water refill places to the OSM. One idea 
which could not only benefit the European Water Project but OSM as a whole is 
to add a tick box on the onosm.org. I could read something like "We do provide 
free water refills" - link to European Water Project. If we would promote the 
onosm.org a bit more not only numbers of businesses aware of/on OSM would 
increase, + people aware of Water Project. Water Project volunteers (if there 
are any) could direct businesses to onosm.org for ease of adding info, this way 
we would "kill two birds with one stone" - as we say where I come from.

cheers,
dzidek23


 
  
 Dnia 13 marca 2020 16:03 talk-gb-requ...@openstreetmap.org napisał(a): 
 
 Send Talk-GB mailing list submissions totalk...@openstreetmap.org
To subscribe or unsubscribe via the World Wide Web, visit 
https://lists.openstreetmap.org/listinfo/talk-gbor, via email, send a message 
with subject or body 'help' totalk-gb-requ...@openstreetmap.org
You can reach the person managing the list attalk-gb-ow...@openstreetmap.org
When replying, please edit your Subject line so it is more specificthan "Re: 
Contents of Talk-GB digest..."

Today's Topics:
  1. Re: European Water Project - Introduction (Colin Smale)  2. Re: European 
Water Project - Introduction (Tony OSM)  3. Cancellation of Nottingham pub 
meetup scheduled for 17th March (SK53)  4. Re: European Water Project - 
Introduction (Peter Neale)

--
Message: 1Date: Fri, 13 Mar 2020 13:12:15 +0100From: Colin Smale 
To: Daniel Holsey Cc: European 
Water Project 
,talk-gb@openstreetmap.orgSubject: Re: 
[Talk-GB] European Water Project - IntroductionMessage-ID: 
<29886cc9030c6a1cc989733c3fbec...@xs4all.nl>Content-Type: text/plain; 
charset="utf-8"
Daniel, that is completely uncalled for. If you can't live and let live,take 
your own advice and go procreate somewhere else. 
On 2020-03-13 12:27, Daniel Holsey wrote:

Fuck Off 
On Fri, 13 Mar 2020 at 10:31, European Water Project 
 wrote: 
Hello, 
My name is Stuart Rapoport. This my first message on the UK OSM forum, so I 
decided to give an introduction to our project before jumping into the thread 
regarding the tag drinking_water:refill = yes.  
A small group of us have recently started a project called European Water 
Project. Our project is 100% collaborative and 100% open data, powered by OSM 
and wikidata. Our goal is to help empower individuals to reduce single use 
waste in their lives. With the help of many (including OSM members in Italy, 
Switzerland, France, and Spain), we have written a set of instructions 
available in 7 languages for adding new water fountains to OSM and as well as 
instructions on how to add photos to Wikimedia Commons and link them back :  
https://meta.wikimedia.org/wiki/Wikimedia_CH/Project/European_Water_Project 
We have developed a Progressive Web Application which allows individuals to 
find nearby locations where they can refill their sustainable water bottle for 
free anywhere in Europe.We strive to contribute to the builiding of a 
collaborative network of foutains, cafes, restaurants and other establishments 
which are willing to allow individuals to fill up their water bottle as part of 
the battle agains single-use waste.  There are currently over 235,000 fountains 
and 70 cafés available on the App. 
Our web App is available directly at https://europeanwaterproject.org  
(installation instructions are in the hamburger menu).  
A description of the project and the project genesis : 
https://drive.google.com/open?id=1f0dts-RErPepgrEnddSAOh1rDqpxMYC3 
Best regards,
Stuart Rapoport
___Talk-GB mailing 
listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb 
___Talk-GB mailing 
listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb--
 next part --An HTML attachment was scrubbed...URL: 
<http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20200313/5e67a2fc/attachment-0001.htm>
--
Message: 2Date: Fri, 13 Mar 2020 12:18:37 +From: Tony OSM 
To: talk-gb@openstreetmap.orgSubject: Re: [Talk-GB] 
European Water Project - IntroductionMessage-ID: 
Content-Type: text/plain; 
charset="utf-8"; Format="flowed"
I completely agree with Colin
On 13/03/2020 12:12, Colin Smale wrote:

Daniel, that is completely uncalled for. If you can't live and let live, take 
your own advice and go procreate somewhere else.

On 2020-03-13 12:27, Daniel Holsey wrote:

Fuck Off
On Fri

[Talk-GB] Fw: European Water Project - Introduction

[Peter Neale via Talk-GB]

For the avoidance of doubt (and to retain my good name), can I please point out 
that "this swearing jerk" referred to by @BrianPrangle is not me but...
>- Forwarded message ->From: Daniel Holsey >To: 
>European Water Project >Cc: 
>"talk-gb@openstreetmap.org" >Sent: Friday, 13 March 
>2020, 11:29:24 GMT>Subject: Re: [Talk-GB] European Water Project - Introduction
>Fuck Off


Regards,Peter
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb 

   - Forwarded message - From: Brian Prangle To: 
talk-gb@openstreetmap.org Sent: Friday, 13 March 
2020, 18:00:10 GMTSubject: Re: [Talk-GB] European Water Project - Introduction
 Can an admin please remove this swearing jerk from the mailing list, for 
totally unacceptable behaviour?

On Fri, 13 Mar 2020 at 16:03, Peter Neale via Talk-GB 
 wrote:

Well. That's a powerful, reasoned argument (NOT!).
If you don't have anything constructive to add to the debate   I suggest that 
you keep your opinions to yourself.
Peter

Sent from Yahoo Mail on Android 
 
  On Fri, 13 Mar 2020 at 11:29, Daniel Holsey wrote:   
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] European Water Project - Introduction

[Peter Neale via Talk-GB]

Well. That's a powerful, reasoned argument (NOT!).
If you don't have anything constructive to add to the debate   I suggest that 
you keep your opinions to yourself.
Peter

Sent from Yahoo Mail on Android 
 
  On Fri, 13 Mar 2020 at 11:29, Daniel Holsey wrote:   
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-ie] OSM at LoveDataWeek 2020 - Maynooth University

[Peter Mooney]

Hello everyone,

I'm giving a general overview talk about OpenStreetMap in Maynooth
University next week, as part of Love Data Week 2020. Details are here [1].

I only have an hour so I want to show attendees what kinds of applications
OpenStreetMap is being used for in Ireland and beyond. This will include
quick examples of downloading data, using Turbo Overpass online, and a very
basic map using Leaflet. I'll be showing the work of OSM IE (example the
recent Kilkenny work), Townlands, Hieki's visualisations, etc.

If you have any other really interesting examples of OSM use which would be
good for a general audience, please let me know and I'd be delighted to
include it.

I will make my slides openly available in ODP format afterwards, if they
are useful for someone else.

With every best wish,

Peter

[1] https://www.maynoothuniversity.ie/library/events/love-data-week-2020
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-GB] Still too many universities in Cambridge

[Peter Neale via Talk-GB]

 >On Tuesday, 4 February 2020, 16:40:21 GMT, Andy Townsend  
wrote:      >   >On 04/02/2020 15:37, Peter Neale via Talk-GB wrote:
  
 
    >>There isn't, I'm afraid.. it's a right hotchpotch
  
   >>IMHO, it would be a waste of time, if you tried to create a single area 
object (do I mean "closed way"?) to be the >>university.  That would just be 
most of the city centre.    
   >>The University is a collection of colleges, so could be a relation...   
...except that each college is probably in >several buildings and they may not 
be in a contiguous area, so each college might have to be a relation of 
>buildings.  So you would have a hierarchy of relations. 
  
   >... or, if the general feeling is to go ahead with this change, just add a 
node in the vicinity of the Senate House / St Mary's  >Church for it.  It'd be 
no less wrong. 
>By the way, there is at least one "sensibly mapped" university in Cambridge:
 
>https://www.openstreetmap.org/way/3987047
 
>Best Regards,
 
>Andy
 Yes, that indeed is fine, but then it is a single campus, which even a tourist 
could identify.  
The problem with THE Cambridge University  (as with Oxford,also) is that the 
colleges are all over the town and there is no campus.  Blame the founders in 
of the colleges in the thirteenth and fourteenth Centuries, who clearly gave no 
thought to the poor mappers in OSM.     

 
 ___
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] Still too many universities in Cambridge

[Peter Neale via Talk-GB]

>> (Ironically, the current tagging makes it hard for me to search to see
>> if there's a "proper" amenity=university in there somewhere, e.g. as a
>> relation or area covering a large swathe of them.)
>
>There isn't, I'm afraid.. it's a right hotchpotch

IMHO, it would be a waste of time, if you tried to create a single area object 
(do I mean "closed way"?) to be the university.  That would just be most of the 
city centre.   
The University is a collection of colleges, so could be a relation...   
...except that each college is probably in several buildings and they may not 
be in a contiguous area, so each college might have to be a relation of 
buildings.  So you would have a hierarchy of relations.
Then, I assume that there will be some buildings that belong to the University, 
but not to any college.  That was certainly true of my Uni (it lies about 70 
miles West of Cambridge and is a darker blue), where the Engineering Building, 
Physics labs, Museum, Examination Halls were all University assets. We used to 
enjoy the look of puzzlement on the faces of (mostly American) tourists, who 
stood in the middle of town, surrounded by colleges, mixed in with shops, 
offices and other buildings, and asked which way to go to the University.
Regards,Peter

On Tuesday, 4 February 2020, 15:15:38 GMT, Dave F via Talk-GB 
 wrote:  
 
 On 04/02/2020 14:28, Dan S wrote:
> Hi Dave,
>
> I agree with what you suggest. Can we be a bit precise though about
> what you propose? You're proposing to remove amenity=university from
> building=university in Cambridge, and make no other tagging changes?

That's correct. I'm going to load the 1050 return by this overpass query 
into JOSM:
[bbox:{{bbox}}];
nwr[amenity=university][building=university];
out meta geom;

plus another 7 which are still tagged as building=yes.

> (Ironically, the current tagging makes it hard for me to search to see
> if there's a "proper" amenity=university in there somewhere, e.g. as a
> relation or area covering a large swathe of them.)

There isn't, I'm afraid.. it's a right hotchpotch

https://overpass-turbo.eu/s/QnH

These are the remaining 117 amenity=university which will need to be 
rectified at a later date..

Cheers
DaveF
> Op di 4 feb. 2020 om 14:15 schreef Dave F via Talk-GB
> :
>> Hi
>> There was a discussion 5 years ago. There may have been others.
>> https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html
>>
>> Many amenity=university tags were added unnecessarily to building=yes
>> A contributor had converted these to building=university, in accordance
>> with the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity
>>
>> https://www.openstreetmap.org/changeset/40649767
>> This allows the removal of the amenity tags without loss of data.
>>
>> The user who created his disparate tagging schema has had plenty of time
>> to rectify.  I think this should be performed now.
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb


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

Re: [Talk-dk] I har selvfølgelig set det, men ... :-)

[Peter Leth]

Kære alle

Det var min ide at eleverne skulle prøve kræfter med OSM.
Jeg har fået en rigtig god sparring med Søren Johannesen (da vi har lavet
et tilsvarende projekt for en 5-6 år siden med 30 unger der gik i 8. klasse
som sad en hel aften mens der var Danmarksindsamling og knoklede. Den gang
ville DR hellere dække deres event uden vores historie).

Det er mig der har stået for projektet, som er en del af de ideer jeg har
til udbredelse og forståelse for brugen af åbne platforme og værktøjer.
Jeg var med til at stifte foreningen OpenDenmark sidste forår, og en del af
det projekt jeg lavede på Ringkøbing Skole er at teste nogle ideer af på
eleverne netop i forhold til at forstå at det åbne både har noget at give
os, men også at vi kan være den der giver noget til andre.

Konkret omkring brugen af OpenStreetMap med en femte klasse, så vil jeg
sige at det er ikke min plan at rulle et projekt ud i den aldersgruppe.
Jeg oplevede at mange af eleverne havde fin forståelse for hvad de lavede,
men jeg oplevede også nogle elever, der var lidt løse kanoner. 5.klase er
derfor de absolut yngste, at redigere sammen med.

Jeg håber virkelig at de bidrag jeg er skyld i, ikke svækker eller
forringer kortet.

Men jeg håber virkelig også at vi via OSM kan være med til at lave
aktiviteter der sigter direkte på nogle af de spørgsmål som er supervigtige
at have med i undervisningen, at åbne licenser, åbne platforme og åbent
indhold er vigtig at kende, fordi det er frisættende for både mennesker og
den teknologi vi omgiver os med.

Eleverne lavede også andre ting den dag - og materialerne og erfaringerne
er på vej til at blive et nyt undervisningsmateriale, som forhåbentlig gør
at vi kan hjælpe skoler, lærere og elever til at lære om at noget er åbent.
(Se fx mapillaryproduktionen her
https://www.mapillary.com/app/?lat=56.096162968244414=8.26761465519428=14.253318058636149=map
 )

Er der personer her i gruppen, der har spørgsmål, kommentarer eller ikke
mindst forslag til hvad jeg kan gøre i den sammenhæng, skal I være velkomne
til at kontakte mig.

God søndag.

/ Peter Leth

Den lør. 1. feb. 2020 kl. 19.13 skrev Soren Johannessen <
soren.johannes...@gmail.com>:

> I kan også høre det som radiointerview på DR4 i går - spol hen på 3
> timer og ca. 10 min
> https://www.dr.dk/radio/p4vest/p4vest-morgen/p4-morgen-2020-01-31-06-05
>
> Før kommer interview med drengen Daniel , (kommer en sang derefter) så
> med underviseren, så går der ca. 15 min (nyheder/musik), hvor dernæst
> så hører vi NGO'erne synspunkt vedr. børnenes event i går.
>
>
>
>
> On Sat, Feb 1, 2020 at 6:39 PM Anders Lund  wrote:
> >
> >
> https://www.dr.dk/nyheder/regionale/midtvest/11-aarige-daniel-giver-digital-noedhjaelp-finder-veje-og-soeer-til-folk-i
> >
> >
> >
> >
> > ___
> > Talk-dk mailing list
> > Talk-dk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-dk
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>


-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[OSM-talk] W3C Maps on the Web workshop

[Rushforth, Peter (NRCan/RNCan)]

Dear Open Street Map community,

I apologize if you are seeing this email for a second time. I sent it 
originally to the talk-ca list, and I was advised that this list might be more 
appropriate.

My name is Peter Rushforth, and I'm with the Canada Centre for Mapping and 
Earth Observation, at Natural Resources Canada (a Canadian government 
department).  We are planning a World Wide Web Consortium (W3C) workshop on 
maps in the Web platform (specifically HTML), together with the W3C and the 
Open Geospatial Consortium (OGC).  The workshop will be collocated with the OGC 
Technical Committee meeting, June 15-17 2020 in Montreal, Quebec.

I am sending this email to see if Open Street Map (especially the Web client 
development teams) might be interested in being invited to participate (by 
presenting a short position paper, in person) in this workshop on the concept 
of better integrating mapping into the Web platform standards, and if so, how 
does Open Street Map see this.  Even if you believe that the Web platform 
standards are already good enough for mapping, it might be worthwhile staking 
that out as a position. If you are interested, though, we would certainly 
welcome OSM to also be part of the program committee.

The objective of the workshop will be to start the conversation between the 
geospatial (and geospatial standards) and Web platform communities, about how 
Web standards could better serve the needs of Web mapping and most especially 
users of Web maps and the Web in general.

Some topics of potential interest include:


  *   a native map viewer, similar to that provided for video content
  *   standards for how such a map widget might integrate with map services and 
APIs
  *   accessibility of browser maps
  *   privacy of user location information
  *   security of browser-based maps
  *   Integration / relationship of maps and location with other browser APIs, 
e.g. geo-video, geolocation API, forms, SVG
  *   crawling, indexing and searching map information
  *   standardized browser elements and APIs
  *   CSS styling of maps and map features
  *   Map feature creation / input forms
  *   federated map services with linking - aka the Web

Mostly the agenda will be driven by position papers, and what organizations 
like yours want to discuss.  If OSM is interested in sending one or two people 
to present a position, please reply directly to me, and I will ensure that you 
/ they are invited.


Sincerely,
Peter


Peter Rushforth

Technology Advisor
Canada Centre for Mapping and Earth Observation
Natural Resources Canada / Government of Canada
peter.rushfo...@canada.ca<mailto:peter.rushfo...@canada.ca> / Tel: 613-759-7915

Conseiller technique
Centre canadien de cartographie et d'observation de la Terre
Ressources naturelles Canada / Gouvernement du Canada
peter.rushfo...@canada.ca<mailto:peter.rushfo...@canada.ca> / Tél: 613-759-7915

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

[Talk-ca] W3C Maps on the Web workshop

[Rushforth, Peter (NRCan/RNCan)]

Dear Open Street Map community,

I apologize if this email gets duplicated. I sent it once without joining the 
list.  Please ignore a second version if it gets released.

My name is Peter Rushforth, and I'm with the Canada Centre for Mapping and 
Earth Observation, at Natural Resources Canada (a Canadian government 
department).  We are planning a World Wide Web Consortium (W3C) workshop on 
maps in the Web platform (specifically HTML), together with the W3C and the 
Open Geospatial Consortium (OGC).  The workshop will be collocated with the OGC 
Technical Committee meeting, June 15-17 2020 in Montreal, Quebec.

I am sending this email to see if Open Street Map (especially the Web client 
development teams) might be interested in being invited to participate (by 
presenting a short position paper, in person) in this workshop on the concept 
of better integrating mapping into the Web platform standards, and if so, how 
does Open Street Map see this.  Even if you believe that the Web platform 
standards are already good enough for mapping, it might be worthwhile staking 
that out as a position. If you are interested, though, we would certainly 
welcome OSM to also be part of the program committee.

The objective of the workshop will be to start the conversation between the 
geospatial (and geospatial standards) and Web platform communities, about how 
Web standards could better serve the needs of Web mapping and most especially 
users of Web maps and the Web in general.

Some topics of potential interest include:


  *   a native map viewer, similar to that provided for video content
  *   standards for how such a map widget might integrate with map services and 
APIs
  *   accessibility of browser maps
  *   privacy of user location information
  *   security of browser-based maps
  *   Integration / relationship of maps and location with other browser APIs, 
e.g. geo-video, geolocation API, forms, SVG
  *   crawling, indexing and searching map information
  *   standardized browser elements and APIs
  *   CSS styling of maps and map features
  *   Map feature creation / input forms
  *   federated map services with linking - aka the Web

Mostly the agenda will be driven by position papers, and what organizations 
like yours want to discuss.  If OSM is interested in sending one or two people 
to present a position, please reply directly to me, and I will ensure that you 
/ they are invited.


Cheers,
Peter


Peter Rushforth

Technology Advisor
Canada Centre for Mapping and Earth Observation
Natural Resources Canada / Government of Canada
peter.rushfo...@canada.ca<mailto:peter.rushfo...@canada.ca> / Tel: 613-759-7915

Conseiller technique
Centre canadien de cartographie et d'observation de la Terre
Ressources naturelles Canada / Gouvernement du Canada
peter.rushfo...@canada.ca<mailto:peter.rushfo...@canada.ca> / Tél: 613-759-7915

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

Re: [OSRM-talk] OSRM Demoserver - call for hosting volunteers

[Peter Schneider-Kamp via OSRM-talk]

What is the average computational load (CPU and memory) needed for the 10K 
requests/minute?

Cheers,
Peter

From: Daniel Patterson via OSRM-talk 
Reply to: Mailing list to discuss Project OSRM 
Date: Friday, 24 January 2020 at 20.53
To: Mailing list to discuss Project OSRM 
Cc: Daniel Patterson 
Subject: [OSRM-talk] OSRM Demoserver - call for hosting volunteers

Hi all,

On Mar 09, 2020, the TLS certificate for 
router.project-osrm.org<http://router.project-osrm.org> is going to expire.  At 
the same time, Mapbox is going to shutdown our hosting of that service.  As 
many of you have probably noticed, our investment in the OSRM codebase has 
greatly decreased over the last year.

This is a call to the community to see if someone else is willing to take up 
the mantle for running the demo server.  If nobody steps up, then the service 
will stop working on Mar 09, 2020.

The demoserver currently hovers at around 10k requests/minute with peaks up to 
about 50k.

I've also posted a ticket about this at 
https://github.com/Project-OSRM/osrm-backend/issues/5655

daniel
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-GB] Stale Developments

[Peter Neale via Talk-GB]

Hi Robert,
Thanks for producing this new tool.  I had already spotted the Bulldozer icon 
on the "Survey Me" map and, in my local area, I have already:
Updated one Brownfield Site to Construction Site, where work has started after 
years of nothing.Deleted one Construction Site, where there is nothing 
happening on the ground and the local council GIS shows no planning permission 
for development.Updated one small Construction Site of about 15 houses that is 
now complete.
Please keep up the good work providing tools to help us identify where work is 
needed.   
Regards,Peter
On Friday, 10 January 2020, 14:12:33 GMT, Robert Whittaker (OSM lists) 
 wrote:
 
 
 I'd like to announce a new mini QA tool that I've put together for UK
OSMers: Stale Developments: https://osm.mathmos.net/developments/

It finds OSM UK highway and landuse tags with tags values of
construction, brownfield and greenfield, which haven't been edited for
over a year. The idea is that such objects should correspond to
real-life developments, whose status is likely to change on that
timescale. Hence the OSM objects probably need reviewing and updating.

To keep the numbers reasonable, the page above only lists the most
stale objects (no edits for over four years), but the full set of the
data is exposed through my Survey Me tool at
https://osm.mathmos.net/survey/ .

Do take a look if you're interested. I hope this is useful to some of you.

Robert.

-- 
Robert Whittaker

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

[Talk-GB] Fw: Appeal for Help - Amending a Route Relation - NCN Route 51

[Peter Neale via Talk-GB]

Having unexpectedly found myself with a spare hour,  I have had a go at 
amending NCN 51 in central Milton Keynes. 
There are 3 Changesets involved:
#78646743. The main changes. I marked this to be reviewed,  but I do hope that 
nobody wants it reverted because I got a bit carried away.  As part of the edit 
I had to correct a one-way road that isn't really one-way,  but I then carried 
on resolving issues flagged by the iD editor; sorry!
#78651993.  Mopping up. After the main edit, I spotted a few ways that I had 
not removed from the relation, so removed them here. 
#78647795. I have flagged some ways with "fixme". They were part of the old 
route, but now form a spur off the main route. I have asked Sustrans whether 
they consider the spur to be part of NCN 51 and await their response. I could 
tag them with "approach", but I'm not clear whether that would mean that all 
>1000 other ways in the relation would then have to be tagged "main ".
Open for comments / suggestions.
Regards, Peter

Sent from Yahoo Mail on Android 
 
   - Forwarded message - From: "Peter Neale"  To: 
"Talk-gb OSM List"  Cc:  Sent: Thu, 19 Dec 2019 at 
13:54 Subject: Fw: [Talk-GB] Appeal for Help - Amending a Route Relation - NCN 
Route 51  Many thanks to @Richard Fairhurst, @Warin and @ Paul Berry for their 
encouragement and help.  I will have a go at making the amendments using the iD 
Editor.  
I'm not sure how soon that will happen, though, as I hear that Christmas is 
coming and Grandads like me are meant to spend time with their families, not on 
the computer.
Before I start, I have one more question:
@Richard Fairhurst said, "It's more important that the route is unambiguous,  
i.e. the member ways all join to form a single route without unnecessary 
branches and loops."
However, the Sustrans map shows some dead-end branches (presumably to link into 
other infrastructure, such as roads and other cyclepaths).  There are 2 that 
are relevant here; one is marked on the ground (probably because it was part of 
the old route), but the other is not.  I do not propose to include the unmarked 
one, but what about the one that is marked?  Should I include it, or not?  
Regards,Peter



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

Re: [Talk-GB] No Through Road Ahead

[Peter Neale via Talk-GB]

I can see the logic of placing the restriction on the bend, but how long is a 
"long vehicle"?
Is there an official definition?
Peter

Sent from Yahoo Mail on Android 
 
  On Thu, 19 Dec 2019 at 14:30, SK53 wrote:   
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Fw: Appeal for Help - Amending a Route Relation - NCN Route 51

[Peter Neale via Talk-GB]

Many thanks to @Richard Fairhurst, @Warin and @ Paul Berry for their 
encouragement and help.  I will have a go at making the amendments using the iD 
Editor.  
I'm not sure how soon that will happen, though, as I hear that Christmas is 
coming and Grandads like me are meant to spend time with their families, not on 
the computer.
Before I start, I have one more question:
@Richard Fairhurst said, "It's more important that the route is unambiguous,  
i.e. the member ways all join to form a single route without unnecessary 
branches and loops."
However, the Sustrans map shows some dead-end branches (presumably to link into 
other infrastructure, such as roads and other cyclepaths).  There are 2 that 
are relevant here; one is marked on the ground (probably because it was part of 
the old route), but the other is not.  I do not propose to include the unmarked 
one, but what about the one that is marked?  Should I include it, or not?  
Regards,Peter


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

[Talk-GB] Appeal for Help - Amending a Route Relation - NCN Route 51

[Peter Neale via Talk-GB]

NCN Route 51  has been changed in Central Milton Keynes.  It no longer goes 
through the intu Shopping Centre!
I would love to amend the Route Relation, but have no idea how to go about it.  
From following the Tagging Discussions, I think that elements should be added 
in the order that they are traversed, but I would not know where to start.  Do 
I need to use the JOSM Editor?  I have only used the iD Editor so far
Would some kind person either:
a.  Teach me how to amend the Route Relation (and be prepared to hold my hand 
from time to time)or, b.  Take on the task of amending the Route Relation for 
me? I have surveyed the new route on my bike and generated a GPS trace, which I 
am happy to make available (I have already uploaded it to OSM, but can also 
email a copy).I have written a 3-page brief, with maps, which I can, of course, 
provide.  
Regards,Peter
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSRM-talk] Force OSRM to use predefined routes

[Peter Elderson]

Hi
I am new to this list, if my question is out of place please refer me to
the right forum!

I was told that routing engines can be forced to use predefined route types
(I am interested in walking routes), by giving very high weight to ways if
they are a member element of a walking route relation.

This would have to be profile dependant, I guess. I'm just an end user, and
the OSM routing services I know do not offer the option to route along
walking routes. At the same time I see other routing services ("Walking
route planners") offering this option even with a choice of which types of
walking routes to include.

Is this a matter of changing the engine e.g. to enable the use of relation
membership in a routing profile? Is it a matter of changing the routing
profile and should the service provider start use the existing
possiblilities and offer the options to the users? Or can I as a user alter
this somehow?

Fr gr Peter Elderson
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] routing without a path

[Peter Schneider-Kamp via OSRM-talk]

Hi everyone,

We are starting to use OSRM in a research project for autonomous drones. The 
drones should normally fly along existing paths (i.e. ways from OpenStreetMap). 
But there are situations where the drone needs to fly without a path between 
two nodes (as it otherwise would have to make a detour of many kilometres).

We have a custom profile that works well for routing along the kind of paths we 
want to route along. But is there any way that we can tell OSRM to just go from 
one node to another close-by node without a path?

So far the only idea is a bit of a hack: add a new type of path between all 
close-by nodes and add this type of path to the profile (with a lower speed, 
enabling its use but discouraging it).

Any other ideas?

Any inputs/ideas/pointers are appreciated!

Cheers,
Peter
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-se] Märklig kustlinje

[Peter Svensson]

Uppdateringen av kustlinjen släpar efter. Jag tror det kommer lösa sig
själv.

Det verkar inte finnas någon way där kustlinjen nu syns.

Mvh

Den tors 14 nov. 2019 14:39Björn Stenberg  skrev:

> Hej,
>
> Är det någon som kan lista ut vad det är som ger Siarö en vit
> bakgrund/kustlinje som inte syns i någon editor?
>
> Titta på Skutviken här
> https://www.openstreetmap.org/#map=17/59.56153/18.67075
>
> Den är rendrerad på en vit yta som inte finns i datat. I såväl JOSM som iD
> är Skutviken en vanlig havsvik som borde rendreras blå som resten av havet.
> Det är likadant runt hela ön.
>
> --
> Björn (Zagor)
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-GB] Name Suggestion Index

[Peter Neale via Talk-GB]

Hotel Chocolat could be tagged "shop=chocolate", I suppose, but chocolate is a 
sub-set of confectionery, so perhaps it should retain "shop=confectionery", so 
that users looking for a sugar high don't have to search for both 
shop=confectionery and shop=chocolate (and shop=boiled sweets and 
shop=fruit_gums and shop=seaside_rock and)?
Would that make it "shop=confectionery / confectionery=chocolate"?  (I am a bit 
new to the "rules" of tagging) 
Regards,Peter 

On Friday, 8 November 2019, 10:41:28 GMT, Silent Spike 
 wrote:  
 
 I'm a(UK based) maintainer of the NSI repository and can push changes directly 
to it. I haven't been as active lately, but previously was working my way 
through UK brands.
"The Range" is one I've looked at previously but never figured out the most 
appropriate tagging which is why it still isn't in the index (for cases like 
that I'd like to consult the community for some consensus). I'll actually start 
a new thread to discuss this brand today.
"Hotel Chocolat" I believe is shop=confectionery in the index purely because it 
was the established tagging. If there is some community consensus it should be 
changed then that can be done (and this is why the index is so useful, because 
all existing locations matched to the brand via `brand:wikidata` could be 
automatically re-tagged with the preferred value).

If there are brands missing or issues with the current brand tagging I'd 
suggest either:- Open an issue on the repository (or a pull request if you're 
comfortable with git and json) and all contributors will then see it- If you 
don't have a github account and don't want one, just bring things up on this 
mailing list (feel free to email me directly too) and I'll see them and can 
either open an issue or push changes

___
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] accurate GPS

[Peter Neale via Talk-GB]

... and if you had 2 devices, how would you know which is right? You would need 
at least 3 devices, so that you could take a majority vote. 
Actually 5 would better
Or 7, or 9 


Peter

Sent from Yahoo Mail on Android 
 
  On Wed, 9 Oct 2019 at 12:34, Simon Ritchie wrote:  
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Subject: Re: Thomas Cook shops

[Peter Neale via Talk-GB]

But, as I am sure has been said by someone else recently:
a.  A shop is still a shop, even when it is closed.b.  A permanently closed 
shop that still has the signage / branding all over it is still a useful 
landmark.
So, I think I would favour disused:shop=*  That way you know from the outset 
that you won't be able to buy anything there atm, but all the other details, 
like name= can be retained.
Regards,Peter

On Wednesday, 25 September 2019, 14:03:21 BST, Andy Allan 
 wrote:  
 
 On Wed, 25 Sep 2019 at 14:51, Andy Mabbett  wrote:
>
> On Wed, 25 Sep 2019 at 13:38, Dave F via Talk-GB
>  wrote:
> >
> > Because shop=* indicates it is still open for business.
>
> If it does not do so in "shop=vacant" then it does not do so in
> something like "opening_hours = none".

What you're proposing here is "oh no it isn't" tagging, which is
generally frowned on.

amenity = pub <- "yay, this is a pub"
opening_hours = none <- "oh no it isn't"

Any map, app, geocoder etc that doesn't parse the additional tags is
therefore mislead. It's much more preferable to avoid confusion by
changing the main tag, in this case changing the "shop" tag to
something else (like vacant) or removing it entirely by converting it
into disused:shop tag.

Thanks,
Andy

___
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] Next quarters project will be fixmes and notes

[Peter Neale via Talk-GB]

I too have encountered a number of Notes that have been addressed, but not 
formally "Resolved".  (e.g. the name of a business marked on a building that 
now has that name tagged)  I surmise that this is because (in the iD editor, at 
least) the Notes are not visible when in Edit mode, so the mapper adding the 
business name may be unaware that someone else has created a Note, suggesting a 
name.
Could this be changed to make all open Notes appear in the iD Edit window?  How 
could I request it?
Regards,Peter

 

On Tuesday, 24 September 2019, 13:56:09 BST, Tom Hukins  
wrote:  
 
 On Tue, Sep 24, 2019 at 01:24:49PM +0100, Michael Booth wrote:
> Think there should also be an effort to open notes for some fixmes which 
> require a survey, as many go unnoticed.

I'm not an extremely active mapper, but I often encounter fixmes that
have already been fixed and notes that have already been dealt with, but
the note or fixme remains open.

It's easy enough to close the note, or delete the fixme, but the risk of
the duplication you suggest is that mappers need to edit more stale
information as time passes.

If mappers follow the approach you suggest, it would be very helpful to
ensure the new notes refer to the existing fixmes, and the fixmes are
edited to refer to the new notes.

Tom

___
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] Fixing shop=yes, now it no longer renders on the default OSM map

[Peter Neale via Talk-GB]

I am also a complete newbie to Maproulette, but have had a go at a couple of 
shop=yes near me.
Some are easy enough, but others are rather tricky to tag correctly (surprise, 
surprise!), so I'll have to do some more research, both on the ground and in 
OSMWiki, to try to find an in-use tag that is appropriate.
If you need to do a survey, I suggest that you don't hit any of the maproulette 
boxes, but back out and come back when you have done your survey.  (or is that 
too obvious a response ?  no offence intended)
Regards,
 Peter
On Thursday, 5 September 2019, 16:41:34 BST, Jez Nicholson 
 wrote:  
 
 giving it a go as a Maproulette newbie too.
I have shop=yes on a number of locations where I know that there is a shop 
open, but i need to survey in person to check what it is. In Maproulette, would 
that be "Not an issue"? or "Too hard, can't see"? (not expecting Robert to 
know, but someone else might)
On Thu, Sep 5, 2019 at 1:18 PM Robert Whittaker (OSM lists) 
 wrote:

On Tue, 3 Sep 2019 at 12:40, Silent Spike  wrote:
> Perhaps a https://maproulette.org challenge would be a good way to track the 
> progress of this?

I've never really used Maproulette before, but I thought this would be
a good opportunity to have a go. So here's my attempt at a challenge,
for anyone who is interested in using it:
https://maproulette.org/browse/challenges/9051 .

Robert.

--
Robert Whittaker
https://osm.mathmos.net/

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

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

Re: [Talk-dk] Redningsskilte?

[Peter Leth]

Kunne kravet om opdatering ikke imødekommes med en aftale om at
Redningsnummer.dk kommer på denne mailliste - så kan de fortælle at der er
sket noget - og vi kan reagere på det. Så kan der ikke være mange skilte,
der smutter rundt i landskabet

/ Peter Leth

Den tor. 29. aug. 2019 kl. 06.46 skrev Jørgen Elgaard Larsen <
j...@elgaard.net>:

> På http://osm.elgaard.net/ kan man se et kort med de redningsnumre, der
> mangler/er for meget i OSM.
>
> Jeg prøvede at lave en import (se
> https://www.openstreetmap.org/changeset/62107577), men endte med at
> reverte den på grund af fejl/dubletter.
>
> Fejlene burde være rettet nu, så det vil være trivielt at lave en ny
> import. Men det efterlader stadig kravet om opdatering...
>
> Jørgen
>
>
>
> Den 29. august 2019 03.25.02 GMT+07:00, Niels Elgaard Larsen <
> elga...@agol.dk> skrev:
>>
>> Ja, det var da en god ide.
>>
>>
>> ==
>> Ved brug af data fra Redningsnummer.dk accepterer du at opdatere data
>> jævnligt og dermed holde de data du viser omverdenen ajour.
>> ==
>>
>> Hvad betyder det for os?
>> Betyder det at den person, der begynder at importere data til OSM lover
>> at blive med at gøre det?
>>
>> Og hvad hvis personen ikke gør det?
>> OSM kan ikke være forpligtiget til at slette det hele igen.
>>
>> I øvrigt et fjollet krav. For de finder vel ikke på at flytte samme
>> nummer fra een strand til en anden. Og der er ikke noget der forhindrer
>> os I at putte en håndfuld redningsnumre i OSM baseret på fx Mapillary.   
>>
>> ==
>> Seneste opdateringsdato eller udtræksdato skal angives i brugerflade,
>> hvis datasættet trækkes hjem i eget it-system og anvendes eksempelvis
>> til at lave offline løsninger.
>> ==
>>
>> Vi eller OSM kan ikke forpligte brugerfladesystemer til den slags.
>> Men man kan vel sige at selvom selvom redningsnumre kommer i OSM laver
>> vi ikke en decideret offline løsning. Og der vil altid være en
>> opdateringsdato i OSM.
>>
>> Men man kunne jo forestille sig at nogen fx lavede en app, der brugte
>> redningsnumre fra hele verden baseret på OSM og ikke mente de skulle
>> vise opdateringsdatoer i brugerfladen eller ikke kendte til
>> redningsnummer.dk's regler.
>>
>> Jeg spiller bare djævelens advokat her. Jeg synes at det er en god ide.
>> Men måske skulle vi for en sikkerheds skyld spørge dem om det ville være
>> et problem.
>>
>>
>> Anders Hedelund:
>>
>>>  Er der nogen, der har overvejet at inkludere redningsskilte i OSM?
>>>
>>>  Det er de grønne, nummerede skilte, der står på strandene langs vore
>>>  kyster: http://www.redningsnummer.dk
>>>
>>>  Under "download" står der vilkår for anvendelsen, samt div. filer klar
>>>  til brug.
>>>
>>>  Billedresultat for redningsnumre
>>>
>>>
>>>  --
>>>  Med venlig Hilsen Anders Hedelund - and...@xoz.dk  +45 3990 5335 Mob: +45 
>>> 6150 5335 TR: +90 531 831 0220
>>>  Et liv efter overlevelsen: http://iug.dk
>>>
>>>
>>> --
>>>
>>>  Talk-dk mailing list
>>>  Talk-dk@openstreetmap.org
>>>  https://lists.openstreetmap.org/listinfo/talk-dk
>>>
>>>
> --
> Dette er sendt fra min mobiltelefon. Undskyld at jeg fatter mig i korthed.
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>


-- 
*Med venlig hilsen *

*Peter Leth*
*pe...@pluk.dk  *
*l...@creativecommons.dk* 

*T. 5152 2387*
*Skype. peter.leth1*
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-de] Plastikmüll als Layer

[Peter Barth]

Hi,

schau mal ins Archiv der osmf-talk-Liste. Da gab es mal einen Thread
dazu, wo einer für so eine Karte geworben hat. Ich glaube es war die
hier: https://openlittermap.com

Gruß,
Peda


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

Re: [OSM-talk] Announcing the Tabang-AI initiative

[Peter Barth]

Hi Eugene,

Eugene Alvin Villar schrieb:
> Unfortunately, I cannot provide you with a link since we communicated with
> Facebook's OSM team privately. This is completely our own initiative and
> was not initiated from Facebook's side.

who is this "we"/"our", how many people were directly involved in this
communication?

I am a bit worried about your definition of "local community". If this
initiative was driven by the local community, as you say, why is it only 
recently announced on the talk-ph mailing list?

Also, for everyone, especially the local community to follow up, you
could just put the direct messages to the wiki for documentation.

Thanks,
Peda


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

[Talk-GB] How to Fix a "Fix-Me"

[Peter Neale via Talk-GB]

If this is not the correct place / route to seek assistance with this issue, 
please advise me where to go.
I see that, on a new housing estate near me, there are a number of "Fix Me" 
tags on highway=residential, which I would like to fix.  

The tags all say, "noexit? turning_circle? stub?"
These are all streets that link to only one other highway, mostly 
highway=tertiary (i.e. they are cul de sacs / dead ends).
Where the highway=residential is mapped as a single line, I can see that it 
would be sensible to mark whether there is a turning circle, or turning loop, 
at the end and, if there is no exit by vehicle, bicycle, or on foot, to mark it 
as "noexit".  
However, where there is a turning loop, which is already mapped as a looped 
highway, I don't understand what the "FixMe" is asking for.  See, for example 
https://www.openstreetmap.org/node/5111774622
Acording to https://wiki.openstreetmap.org/wiki/Tag:highway%3Dturning_loop, 
"Draw a closed highway=* way around the traffic island and connect it to the 
main road, giving it the same name. If traffic is required to flow in a 
particular direction around the traffic island, add oneway=yes. This method is 
preferred for large turning circles, because navigation applications decide 
whether the user is on- or off-route based on their distance from the roadway. 
This method also makes it possible to accurately map features inside the loop, 
such as parking spaces, trees, or a flagpole.If a turning loop has been mapped 
as a way, do not remap it as a simple node, as that would remove detail from 
the map."
Are these "FixMe"s generated automatically?  Can I just delete the "FixMe" in 
these cases?
I would be grateful for any advice.
Peter


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

Re: [Talk-GB] Tagging a St John's Ambulance base

[Peter Neale via Talk-GB]

...Or, looking at their website, it is a charity, so perhaps that makes it a 
"social facility"?
Oh BTW, it is "St John Ambulance", not "St John's Ambulance" (I don't know why, 
but it is...)
See St John Ambulance - the nation’s leading first aid charity

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
St John Ambulance - the nation’s leading first aid charity

First aid is a simple skill with an incredible impact. We want everyone to 
learn it, so that they can be the dif...
 |

 |

 |


Regards,
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb 

On Wednesday, 10 July 2019, 21:20:36 BST, Peter Neale via Talk-GB 
 wrote:  
 
 Personally, I would have thought of it as a club, in which first aid is 
taught, as a hobby ( No offence intended to any St John volunteers)
Peter

Sent from Yahoo Mail on Android 
 
  On Wed, 10 Jul 2019 at 20:30, Mark Goodge wrote:   

On 10/07/2019 19:08, Ben Proctor wrote:
> Hello mapping people
> 
> There is a building and yard in Hereford used by St John's Ambulance. 
> The building functions as a meeting venue (like a scout hut but for St 
> John's) and some vehicles are stored in the yard.
> 
> https://www.openstreetmap.org/#map=19/52.06051/-2.71419
> 
> How would you tag this?
> 
> It's currently amenity=doctors which doesn't seem right. 
> emergency=ambulance_station doesn't seem to describe this use.
> 
> I was heading down amenity=community_centre route but I'm not sure 
> that's right either.
> 
> A quick search for St John's Ambulance reveals a wider range of 
> approaches in other areas.

I'd be inclined to go for community centre, in this case. It isn't an 
emergency ambulance station, which is what the 
emergency=ambulance_station tag is for (and, in any case, is rapidly 
becoming obsolete with the new distributed means of organising an 
ambulance service), and it isn't a doctor or a clinic either. And the 
main purpose of the building (as opposed to the yard) is for things like 
first aid training (both for St John volunteers themselves and the wider 
community). So a community centre is probably closest.

Mark

Mark

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

Re: [Talk-GB] Tagging a St John's Ambulance base

[Peter Neale via Talk-GB]

Personally, I would have thought of it as a club, in which first aid is taught, 
as a hobby ( No offence intended to any St John volunteers)
Peter

Sent from Yahoo Mail on Android 
 
  On Wed, 10 Jul 2019 at 20:30, Mark Goodge wrote:   

On 10/07/2019 19:08, Ben Proctor wrote:
> Hello mapping people
> 
> There is a building and yard in Hereford used by St John's Ambulance. 
> The building functions as a meeting venue (like a scout hut but for St 
> John's) and some vehicles are stored in the yard.
> 
> https://www.openstreetmap.org/#map=19/52.06051/-2.71419
> 
> How would you tag this?
> 
> It's currently amenity=doctors which doesn't seem right. 
> emergency=ambulance_station doesn't seem to describe this use.
> 
> I was heading down amenity=community_centre route but I'm not sure 
> that's right either.
> 
> A quick search for St John's Ambulance reveals a wider range of 
> approaches in other areas.

I'd be inclined to go for community centre, in this case. It isn't an 
emergency ambulance station, which is what the 
emergency=ambulance_station tag is for (and, in any case, is rapidly 
becoming obsolete with the new distributed means of organising an 
ambulance service), and it isn't a doctor or a clinic either. And the 
main purpose of the building (as opposed to the yard) is for things like 
first aid training (both for St John volunteers themselves and the wider 
community). So a community centre is probably closest.

Mark

Mark

___
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] Typical maxweight signs in USA? (editor developmnent question)

[Peter Dobratz]

Thanks for trying to standardize on this.  I've seen a few of these maximum
weight signs and was unsure of how to tag.

>From what I've seen in the United States, I've seen maximum weights listed
as both lbs (pounds) and tons (where 1 ton = 2000 pounds).

In Portland, Oregon, I've recently come across the following following text
on signs:

WEIGHT
RESTRICTED
BRIDGE
SINGLE AXLE TRUCKS
50,000 LBS MAX
COMBINATION TRUCKS
80,000 LBS MAX

WEIGHT LIMIT REDUCED
ANY SINGLE AXLE 20,000 LBS
ANY TANDEM AXLE 34,000 LBS
ANY GROSS WEIGHT 105,500 LBS
LEGAL AXLE LOADS ONLY

WEIGHT
LIMIT
6
TONS

Reading this page, I see the potential ambiguity extends deeper than I
realized (short ton, metric ton, long ton)
https://en.wikipedia.org/wiki/Tonne

Peter



On Tue, Jun 25, 2019 at 3:35 AM Mateusz Konieczny 
wrote:

> How often weight limit signs other than plain
> "Weight limit X tons"
> https://wiki.openstreetmap.org/wiki/File:MUTCD_R12-1.svg
>
> and
>
> R12-5 https://wiki.openstreetmap.org/wiki/File:MUTCD_R12-5.svg
> appear?
>
> Some of them are listed at
> https://wiki.openstreetmap.org/wiki/Key:maxweight#United_States
> but I am unsure is it case of something actually popular or rare curiosity?
>
> -
>
> I am asking as I work on extending StreetComplete by adding max weight
> quest for bridges
> and I want to support also USA-style weight limits.
>
> 
>
> PS StreetComplete is a bit different editor, available as an Android
> application - it allows to make
> a very limited set of edits, but all can be done by answering simple
> questions with no OSM specific
> knowledge necessary.
>
> PPS In case that somebody used StreetComplete and noticed some stupid and
> preventable behavior,
> reports at https://github.com/westnordost/StreetComplete/issues are
> welcomed (or
> within this thread if someone is unable/unwilling to make a Github account)
>
>
>
> ___
> 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-GB] Snowdonia National Park missing?

[Peter Neale via Talk-GB]

Dave,
Sorry to jump in, but perhaps your response was a little harsh?
Even given such advice, not all mappers will feel confident to fix an issue. 
Perhaps it is better that they ask for help (again), rather than ignore the 
issue, or try to fix it an just make matters worse?
Peter

Sent from Yahoo Mail on Android 
 
  On Tue, 18 Jun 2019 at 21:31, Dave F via Talk-GB 
wrote:   ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] How would tag or name this wall crossing?

[Peter Neale via Talk-GB]

Sorry, but, to me at least, a "chicane" involves a (double) bend.
See: https://en.oxforddictionaries.com/definition/chicane
" NOUN1.  A sharp double bend created to form an obstacle on a motor-racing 
track or a road."
and these seem to involve a narrow "sqeeze", not a double bend.
 Peter 
On Saturday, 27 April 2019, 18:12:54 BST, Martin Wynne  
wrote:  
 
 barrier=stile seems unhelpful to me if rendered as a normal stile 
symbol, for walkers needing to know if they will have to climb any.

barrier=chicane would perhaps be more descriptive?

Martin.

___
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] How would tag or name this wall crossing?

[Peter Neale via Talk-GB]

Running Overpass Turbo, it seems that they are concentrated in a small area, so 
probably "hipster" is a local term.
Looking at a well-known global Aerial Imagery source, with links to Street 
level photography, shows at least 2 of them (adjacent to roads) to be narrow 
gaps in stone walls, so a version of "squeeze". 
Regards,
 Peter 
On Saturday, 27 April 2019, 17:54:03 BST, Andy Townsend  
wrote:  
 
 
On 27/04/2019 17:50, Philip Barnes wrote:
>
> https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dstile#Stile_details
>
4000 of those:

https://taginfo.openstreetmap.org/keys/stile#values

However also from that page I'm now wondering what "stile=hipster" (!) is?

Best Regards,

Andy



___
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-se] Naturvårdsverkets nya Nationella MarktäckeData

[Peter Svensson]

Jag har laddat ner Linköping (i morse) och det ser ut som väldigt mycket
konflikter. Nya skogspolygoner i befintliga och nya skogspolygoner som skär
befintliga skogspolygoner.  En del vägar har väldigt mycket "trappform" med
vägar i 90 räta graders vinklar norr/syd/öster/väster där det kanske borde
ha varit diagonalt.

Men jag undrar främst vad de tre olika sorters filerna innebär: 1. base 2.
conflated 3. filtered. Vilken är det som är "kandidat för import" så att
säga och vilken manuell process behöver genomföras?

Slutligen mina egna tankar, rent generellt om en import av denna typen:

Personligen kan jag tycka att det kanske är för mycket (små-) detaljer i
datat. Om fokus hamnar mer på stora områden som idag saknar landcover så är
det lättare att manuellt senare lägga till detaljer och öka noggrannheten
för framtida mappare. Om man istället importerar massa smådetaljer (med
mycket brus och komplicerade genometrier) så är det mycket svårare att
förbättra efteråt...

mvh

On Wed, Apr 17, 2019 at 11:30 AM Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:

> Hej Karl-Johan!
> Tack för ditt intresse!
>
> >Jag har laddat ner filerna och för Linköpings kommun och det är ganska
> mycket konflikter
> Hur stort antal konflikter du ser? Handlar det om hundratals eller
> tusentals problem? Linköpings kommun är redan väl kartlagd:
> http://paul7.net/i/2019.04.17/1b0e/linkf6pings-kommun.jpg . Du kanske
> vill fokusera endast på de södra och söder-östliga delarna som nu är
> "vita".  I så fall radera manuellt alla nya (eller bara konflikterande)
> objekt utanför dessa delområden.
>
> >Ska jag anteckna mig på "Status_per_subarea
> "
>  för
> de kommuner jag tänker mig ge mig på eller bara på den som jag just nu
> jobbar på?
> Det är väl okej att reservera två eller tre kommuner för sig, tror jag.
> Det är också intressant att se på vad som händer med importdatat vid
> intilliggande områdens gränser — denna fråga har jag inte tänkt igenom.
> Kommunerna är ju inte skilda öar i havet…
>
> Jag har också släppt v2-versionen på datat. Det är mer filtrerad, så
> kanske passar det bättre för större subareor.
>
>
> Среда, 17 апреля 2019, 8:24 +03:00 от Karl-Johan Karlsson <
> karl.johan.karls...@gmail.com>:
>
> Hej!
>
> Jag tänkte ta mig an Linköpings och kanske några omkringliggande kommuner.
> Jag har laddat ner filerna och för Linköpings kommun och det är ganska
> mycket konflikter så ... det kanske är bättre att börja med någon mindre
> för att "öva" på. Hur gör vi för att undvika dubbelarbete? Ska jag anteckna
> mig på
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea
> för de kommuner jag tänker mig ge mig på eller bara på den som jag just nu
> jobbar på?  Hur som helst så borde jag nog skapa ett "import account". Jag
> ska se om jag får mer tid ikväll ...
>
> Den ons 17 apr. 2019 kl 00:22 skrev Grigory Rechistov via Talk-se <
> talk-se@openstreetmap.org
> >:
>
> Hej,
>
> Nu är den första varianten på nastän uppladdningsfärdiga OSM-filer för 288
> av 291 kommuner tillgängliga. Länken till ziparkiven finns i tabellen här:
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea
> . Om ni har tid, vänligen ladda ner någon fil, packa den upp och kika in,
> om dess innehåll är vettigt eller helt vansinnigt.
>
> Ett slags guide som beskriver hur man manuellt rättar till kvarstående
> konflikter finns här:
> https://wiki.openstreetmap.org/wiki/Catalogue/NMD_2018_Import_Plan/Sammanblandningsguide
>
> I princip är jag redo att ladda upp Vingåkers kommun när som helst men
> väntar för ytterligare feedback av imports@osm
>  mejllistan
>
> Ett par anmärkningar.
> 1. Nu håller jag på att skapa en annan revision på OSM-filer som har ännu
> färre mindre detaljer och respektive mindre storlekar. De lär bli nyttiga
> för riktigt stora kommuner. Ska ladda dem upp imorgon.
> 2. Det finns några få kommuner som är ganska stora. Det är oklart ännu om
> man alls kan lyckas att ladda dem upp. Men Kirunaområdet verkar vara den
> hårdaste muttern att spricka. Dess bearbetning kraschade min dator två
> gånger eftersom det var så stort och datorminnet tog slut. Jag anstränger
> mig att förenkla datat ännu mer. Om ingenting hjälper ska jag klippa det i
> mindre delområden. Tills det, finns det 288 andra områden att leka med.
>
> Воскресенье, 14 апреля 2019, 23:11 +03:00 от Grigory Rechistov <
> ggg_m...@inbox.ru 
> >:
>
> Nu kommer discussionen på Imports mejllista:
> https://lists.openstreetmap.org/pipermail/imports/2019-April/005958.html
>
> Med vänliga hälsningar,
> Grigory Rechistov
> With best regards,
> Grigory Rechistov
>
>
>
> С наилучшими пожеланиями,
> Григорий Речистов.
> Med vänliga hälsningar,
> Grigory Rechistov
> With best regards,
> Grigory Rechistov
> ___
> Talk-se mailing list
> 

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Peter Svensson]

Jag har tittat på https://atakua.org/p/nmd/vinon-3.osm.gz och har en fråga:

Om man tittar på områdena kring nod -1424890 (59.18809091653,
15.73068800312) så har området öster om (way -1434062), samt väster om (way
-1434100) denna nod exakt samma uppsättning tags:

"landuse"="forest"
"leaf_type"="broadleaved"
"source"="NV NMD2018"
"leaf_cycle"="deciduous"

Borde inte detta betyda att dessa områden med bör slås ihop till ett enda
större område?

mvh

On Fri, Apr 5, 2019 at 9:39 PM Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:

> Och samtidigt fortsätter jag förbättra mina skript. Skriptet finns här
> https://gist.github.com/grigory-rechistov/39c7e329cb1f9b42a97ca5960377173d
> och det tar in en OSM fil som är direkt konvertering av en GeoJSON-fil. Den
> sistnämnda filen kommer med de ursprungliga "DN"-taggarna. Sedan förbättrar
> skriptet innehållet:
>
> 1. Ersätter "DN=nummer" taggar med "landuse=*" taggar enligt schemat
> beskrivet här:
> https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/NMD_2018_Import_Plan#Tagging_Plans
> .
> 2. Alla onödiga polygoner (vatten, byggnader osv) tappas bort
> 3. Alla duplicerade noder slås samman
> 4. Alla självkorsningar rättas till.
>
> Den resulterande OSM-data har nu noll fel och betydligt mindre varningar
> efter valideringen.
> Här är min processen med dataimporteringen på Vinön
> https://osm.org/go/0ZoM9_P?m= . Jämfört med Gränsön anser jag att den har
> förbättrats, på stort sätt.
>
> 1. Den ursprungliga GeoJSON https://atakua.org/p/nmd/vinon.geojson.gz och
> motsvarande OSM: https://atakua.org/p/nmd/vinon-0.osm.gz har runt 1
> problem.
> 2. Efter att mitt skript körs finns det bara 137 varningar av samma typ på
> ca 16000 nya noder. Se bilden: https://atakua.org/p/nmd/vinon-1.png och
> datafilen: https://atakua.org/p/nmd/vinon-1.osm.gz
> 3. Efter att jag manuellt söker alla mindre polygoner (färre än 10 noder)
> och slänger dem kvarstår bara 18 varningar att rätta till. Jag vill
> nämligen förbättra skriptet så att det automatiskt raderar mindre
> polygoner. Bilden: https://atakua.org/p/nmd/vinon-2.png och OSM-filen:
> https://atakua.org/p/nmd/vinon-2.osm.gz
> 4. Samtliga kvarstående problem är att två polygoner sammanfaller, varav
> den ena är inre väg (utan taggar) i en multipolygon och den andra bär
> taggar. Jag anser att orsaken är faktiskt en inkorrekt import från GeoJSON.
> Det går att rätta till problemet automatiskt i mitt skript, men jag hann
> inte göra det ännu.
> 5. Hur som helst, noll problem kvar efter 10 minuter manuellt arbete!
> Bilden: https://atakua.org/p/nmd/vinon-3.png och OSM-filen:
> https://atakua.org/p/nmd/vinon-3.osm.gz
>
> Nu minns jag att man har märkt att raka linjer längs vägar ser ut som
> zig-zag eller sågtänder: https://atakua.org/p/nmd/zigzagf%c3%a4lt.png .
> Det går enkelt att rätta det till manuellt.
> Det "förenkla yta (Skift-Y)" verktyget i JOSM med max-error=20 (
> https://josm.openstreetmap.de/wiki/Help/Action/SimplifyWay) förvandlar
> den fula saken till en helt rak sträcka:
> https://atakua.org/p/nmd/f%c3%b6renkla-yta.png
>
> Пятница, 5 апреля 2019, 17:19 +03:00 от Grigory Rechistov <
> ggg_m...@inbox.ru>:
>
> Hej!
>
> > Engligt https://wiki.openstreetmap.org/wiki/Import/Guidelines ska man
> även dokumentera sådana kommande importeringar och tillkännage dem. Finns
> det någon som är intresserad att fylla i Import/Catalogue-sidan och skriva
> en plan?
>
> Okej, så här är mitt utkast på en importeringsplan:
> https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/NMD_2018_Import_Plan.
> All feedback är välkommen!
>
> Jag tänker att skriva till impo...@openstreetmap.org
>  tillkännage
> importeringen i några dagar.
>
>
>
> Med vänliga hälsningar,
> Grigory Rechistov
> With best regards,
> Grigory Rechistov
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Peter Svensson]

Hej!

Det ser ut som att det finns många noder som ligger precis i linje, eller
nära nog i linje. Verkar som att vägarna är genererade med ett påtvingat
maximalt avstånd till nästa nod. De mellanliggande noderna skulle man kunna
reducera. Man får väl labba fram någon lämplig toleransgräns, såsom att
alla noder som kan tas bort utan att vägens sträckning flyttar sig mer än
max någon decimeter, bör tas bort.

mvh zvenzzon

On Thu, Apr 4, 2019 at 12:46 AM Grigory Rechistov via Talk-se <
talk-se@openstreetmap.org> wrote:

> Hej,
>
> > Detta beror nog på att stil-beskrivning inte kommer med. Det är med
> andra ord inget fel på datat.
> Jaha. Jag var nämligen för lat att felsöka det och därför valde att
> filtrera mindre polygoner vid GeoJSON -> GeoJSON transformeringen i min
> egen skript.
>
> Jag är nu mycket nöjd med det resultat som jag fick med
> v.generalize-filtern för Gränsö. Ni är gärna välkomna att bedöma och
> kommentera på resultatet själva. Vidare ger jag länkar till den slutliga
> OSM-filen som jag vill ladda upp imorgon, om ingen är emot detta förstås.
> Alla nya objekt är taggade med "source=NV NMD2018", så ifall det upptäcks
> några problem med min kommande uppladdning kan man enkelt hitta och radera
> den.
>
> Sammanfattat är det min dataförbearbetning: GeoTIFF -> klippa GeoTIFF ->
> raster till vektor i QGIS -> tillämpa v.generalize -> spara som GeoJSON ->
> konvertera "DN" taggar till "landuse" taggar med hjälp av min egen skript
> -> importera i JOSM -> spara som OSM XML -> redigera XML för att fixa
> geojson-plugins buggar -> ladda OSM XML i JOSM igen. Jäkligt flera steg,
> jag vet...
>
> Här är vad jag slutligen öppnat i JOSM:
> https://atakua.org/p/nmd/granso-semiautomatisk.osm
>
> Den första valideringen visade tio tusen fel och varningar! Skärmbilden:
> https://atakua.org/p/nmd/import-stage-1-errors.png  . Det gick ändå att
> fixa de absolut flesta av dem automatiskt genom att klicka på "rätta till"
> knappen. Duplicerade noder med samma koordinater härstammar visserligen
> från det 10 meter rutnätet i rastern. Men JOSM är smart nog för att slå dem
> ihop.
>
> Sedan var det en jättelång sträcka:
> https://atakua.org/p/nmd/import-stage-2-errors.png längre än 2000 noder.
> Det felet löste jag genom att stycka polygonen i tre delar.
>
> Sedan blev det inga mer allvarliga fel utan endast varningar:
> https://atakua.org/p/nmd/import-stage-3-errors.png. De krävde dock
> manuell städning. I de flesta tillfällen vad som krävdes var att radera ett
> extra objekt eller slå ihop flera.
>
> Självkorsningarna är de mest påfrestande typen problem:
> https://atakua.org/p/nmd/typisk-sjalvkorsning.png. JOSM kan inte rätta
> till dem automatiskt. Jag behöver antingen radera den punkt som står i
> självkorsningen, eller radera den hela "öglan".
>
> Här är hur den sista fasen på manuellt arbete ser ut:
> https://atakua.org/p/nmd/import-stage-varningar.png
>
> Slutliga OSM-filen: https://atakua.org/p/nmd/granso-fixade-fel.osm
>
> Jag ska bli tacksam för all feedback! Och förlåt för det här jättelånga
> mejlet.
>
>
> Среда, 3 апреля 2019, 23:39 +03:00 от Christian Asker <
> christian.as...@gmail.com>:
>
> Hej.
>
> 1. Detta beror nog på att stil-beskrivning inte kommer med. Det är med
> andra ord inget fel på datat.
>
>
> Du kan nog slå ihop flera olika värden med Raster Calculator i QGIS.
> Personligen är jag dock inte övertygad om att det är rätt väg att gå. Har
> vi detaljerad information om skogstyp kan vi väl behålla den. Noggrannheten
> är nog inte sämre än vad som kan åstadkommas med andra metoder.
>
> Mvh Christian
>
>
>
>
> Grigory Rechistov via Talk-se  skrev: (3 april
> 2019 22:22:14 CEST)
>
> Hej,
> För att fixa "trapporna" som kvarstår efter gdal_polygonize försökte jag
> använda en insticksmodul v.generalize av GRASS-verktyg (se frågan här:
> https://gis.stackexchange.com/questions/3/how-to-smooth-large-vector-polygons-from-raster).
>
>
> Här är hur linjerna på Gränsö (https://osm.org/go/0aUFbLO0-?m=) ser ut:
> https://atakua.org/nc/index.php/s/2kiEafMdYGQDyk6
> . Någorlunda
> bättre men visst inte perfekt.
>
> Nu kämpar jag med flera mindre irriterande problem såsom:
> 1. Att filtrera mindre krafspolygoner. gdal_sieve förvandlar den
> ursprungliga TIFF-filen till svartvitt, av någon anledning
>
> 2. Att komma runt buggar i GeoJSON import (
> https://github.com/JOSM/geojson/issues/29#issuecomment-479502069). Det
> saknas också "type=multipolygon" taggen efter importen.
>
> Det verkar att jag verkligen vill slå samman olika typer skogar för att
> minska det brus de skapar. Då behöver ja ett kommandoradsverktyg eller en
> QGIS-plugin som kan redigera raster och slå olika pixelfärger till en färg.
>
>
> Med vänliga hälsningar,
> Grigory Rechistov
> With best regards,
> Grigory Rechistov
>
>
> --
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
>
>
>
> С наилучшими пожеланиями,
> Григорий Речистов.
> Med vänliga 

Re: [Talk-se] Tile server down?

[Peter Magnusson]

The SSL certificate has expired.
Some admin will hopefully notice :)

Den tis 2 apr. 2019 kl 12:47 skrev Brian Gaze via Talk-se <
talk-se@openstreetmap.org>:

> Hi,
>
> Is there currently a known problem with the OSM tile sever?
>
> https://tile.openstreetmap.se
> <https://tile.openstreetmap.se/hydda/full/%7Bz%7D/%7Bx%7D/%7By%7D.png>
>
> I'm not able to access.
>
> Best Regards
>
> Brian
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>


-- 
-
Peter Magnusson
mailto:pe...@bjorkvagen2.se
mob:0702-633276
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Peter Neale via Talk-GB]

Thanks to all for the helpful responses.
I have looked (again) at the OSM Tags for Routing at 
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#United_Kingdomfrom
 which it is clear that foot=yes (for example) is implied by highway=cycleway.
However, Andy's question (if I understand it correctly) set me wondering 
whether there is any need to / benefit from distinguishing between foot=yes and 
foot=designated, etc.  
MK council, in their public mapping, imply that Redways are NOT (generally / 
universally) PROW.  However, they DO seem to be "designated" for foot and cycle 
(and wheelchairs etc.), so perhaps they should be tagged; bicycle=designated; 
foot=designated,etc.,which highway=cycleway does not imply.
Also, at the end of my original post, I asked:
"NamingI am not aware of any Redways that have unique names (someone will 
probably correct me on this), but I see several on OSM tagged with 
“name=Redway”.  Whilst I can see the attraction of doing this, I suspect that 
would not be considered good practice.  Should I delete that name, whenever I 
see it? "
Nobody seems to have commented on that yet (perhaps it got lost somewhere).  
Any views? 
Regards,

Peter

On Thursday, 21 March 2019, 13:54:20 GMT, Andy Townsend  
wrote:  
 
 On 21/03/2019 13:35, Ed Loach wrote:
> How tagging changes over time...
>
> RichardF wrote:
>> highway=cycleway, segregated=no achieves all that in two tags
>> rather than
>> seven. :)
> I remember
> https://wiki.openstreetmap.org/wiki/Milton_Keynes_Mapping_Party_2009
> where it looks like we (or at least I) only used highway=cycleway, e.g.
> https://www.openstreetmap.org/way/34669428/history
>
If they have some legal status beyond being "mere shared cycleways" 
would some sort of designation tag also make sense here?  Currently 
that's used for legal designations such as public footpaths, public 
bridleways (and also I think core paths in Scotland).

Best Regards,

Andy



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

[Talk-GB] Milton Keynes Redways - How to Tag Consistently

[Peter Neale via Talk-GB]

I am relatively new to OSM, but am trying to contribute in a useful way, 
particularly in my local area (Milton Keynes).
Milton Keynes enjoys (among many benefits) an extensive network of joint-use 
Cycle Paths / Foot Paths, known as “Redways” 
https://en.wikipedia.org/wiki/Milton_Keynes_redway_system

Most (if not all) are already mapped in OSM, but the tagging is not consistent, 
so I was considering making small amendments to increase consistency.  However, 
I don’t want to make them consistently wrong, so I am seeking confirmation of 
how they should be tagged.
Official Status of Redways  MK Council publishes a map of the Redway Network, 
https://www.milton-keynes.gov.uk/assets/attach/51668/MK_Redway_Poster_PRINT_NOcrops.pdf
with a “Redway Code”, which states,
“The Redways are an important part of Milton Keynes.  They are shared-use 
routes for people on foot or on cycles.  The traffic free network is popular 
for leisure, for commuting and for staying active.  Redways may be used by 
anyone cycling and walking including people with pushchairs, or prams and those 
in wheelchairs (including powered wheelchairs / mobility scooters).”and,
“Redways and the Law:  Electric cycles which meet EAPC Regulations are 
permitted to use Redways.As Public Highway, all legal requirements and the 
Highway Code are applicable to the Redways: cycles should be roadworthy and 
able to stop in an emergency; cycle lights are required at night.All 
motor-powered vehicles including mopeds, mini-motos and motorcycles are 
prohibited from using Redways, with the exception of authorised vehicles e.g. 
emergency vehicles and maintenance vehicles.”
An Old RelationI have found a previous Relation, 
(https://www.openstreetmap.org/relation/145144) which I assume linked all the 
Redways, but which @andrewmk deleted some years ago, so I am NOT proposing to 
re-create that Relation.   
Access TaggingSo how should they be tagged for access?I believe it should 
be:highway=path  (but I see several tagged as highway=cycleway and both are 
shown in the Wiki at 
https://wiki.openstreetmap.org/wiki/Tag:highway=cycleway)foot=designatedmotor 
vehicle=permit (to allow the emergency vehicles and maintenance 
vehicles)moped=no bicycle=designatedhorses=not specifiedsegregated=noIs that 
correct?
NamingI am not aware of any Redways that have unique names (someone will 
probably correct me on this), but I see several on OSM tagged with 
“name=Redway”.  Whilst I can see the attraction of doing this, I suspect that 
would not be considered good practice.  Should I delete that name, whenever I 
see it? 
Regards,
 Peter Neale 
t: 01908 309666 
m: 07968 341930 
skype: nealepb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-us] motel vs. hotel

[Peter Dobratz]

How do you distinguish between the tourism=hotel and tourism=motel tags?

The criteria that I was imagining is that a motel is a single story
building where you have the ability to park you car directly outside of
your room. A hotel would be other types of buildings such as multi-story
where most guests cannot park directly outside their room.

There's the curious case of the two Motel 6 facilities directly across the
road from each other.  I had marked these as tourism=hotel based on the
building architecture, but maybe all Motel 6's should be tourism=motel?

https://www.openstreetmap.org/note/1645570

What do you think?

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

Re: [Talk-br] Able to host a tile.osm.org CDN node? (Inglês)

[Peter Krauss]

Sugiro uma vaquinha chamando principalmente pessoas jurídicas... pode ser o
APOIE.ME que é para contribuições recorrentes e já rodou com projeto OSM-BR
<https://apoie.me/osmbrasilcuritiba>.

Nunca instalei tile-server, e não sei como se comporta em *cluster*, vale
perguntar pro Grant.

Quanto ao melhor hosting, deve ter uma dezena, sempre é bom fazer uma
planilha de cotações... Alguns bem conhecidos aqui do Talk-BR,
e que cujas VMs rodam bem com outras ferramentas OSM:
 https://www.digitalocean.com/pricing/
 um pouco mais de US$40/mes pois precisa mais que 5T trafego, equivale
~R$150/mes
 https://www.webfaction.com/
 .. parece mais caro, R$200/mes
  ..
A todas as empresas de hosting vale mandar um e-mail negociando, inclusive
por ser apoio à OSMF dá para chorar um bom desconto.





On Sat, Feb 23, 2019 at 12:57 PM Paulo Carvalho <
paulo.r.m.carva...@gmail.com> wrote:

> 8GB de RAM e 168GB de armazenamento é um requisito pequeno (ao menos em
> relação ao que estou acostumado).  O que complica mesmo é o requisito de
> tráfego de dados.  70Mb/s se traduz em  23TB/mês.  É um requisito grande.
> No AWS (infra da Amazon), a solução mais barata para esse requisito é
> contratar um plano de US$80,00 para ser o servidor master ( 16GB RAM +
> 320GB de disco + 6TB de tráfego).  Para os 17TB restantes, contratar mais
> oito planos de US$5,00 ( 1GB RAM + 40GB de disco + 2TB de tráfego ) apenas
> para compartilhar o link. Sairia tudo por US$120,00 mensais.
>
> Se for possível por o serviço de tiling em cluster, daria para contratar
> 12 planos de US$5,00 ( 1GB de RAM + 40GB de disco + 2TB de tráfego ), que
> seria mais barato ainda (US$60,00 mensais).  Mas, repetindo, para essa
> solução, os programas do OSM têm que poder funcionar em cluster, pois um
> plano de US$5,00 sozinho não atende os requisitos de memória e de
> armazenamento.
>
> AWS é só uma sugestão.  A Google tem planos similares para servidores
> virtuais.
>
> att,
>
> PC
>
> Em sáb, 23 de fev de 2019 às 05:14, Peter Krauss 
> escreveu:
>
>> - - - Tradução do e-mail (fw anexo) do Grant:  - - -
>>
>> Olá OpenStreetMap Talk-BR,
>>
>> Introdução rápida: faço parte da equipe voluntária de Operações
>>https://wiki.osmfoundation.org/wiki/Operations_Working_Group
>> a qual mantém os servidores do OpenStreetMap.org rodando.
>>
>> Nosso servidor CDN (Rede de Fornecimento de Conteúdo)
>>tile.openstreetmap.org
>> seria muito beneficiado por ter um servidor de cache no Brasil.
>> Isso tornaria o mapa renderizado padrão do site OpenStreetMap.org
>> mais rápido para os brasileiros.
>>
>> Veja como estão hoje as conexões da rede CDN por país,
>>   The live CDN Country -> Edge Cache Mapping:
>>   https://dns.openstreetmap.org/tile.openstreetmap.org.html
>>
>> Conhece alguém que possa ajudar?
>> Estamos procurando idealmente um servidor físico dedicado ou VM poderosa
>> com 8 GB ou + de RAM e pelo menos 146 GB de armazenamento.
>> Mais detalhes em
>>   https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN
>>
>> Nosso atual pico de tráfego no Brasil é atualmente de cerca
>> de 70.000.000 bits por segundo.
>>
>> Discriminação completa, em bits por segundo:
>>
>> https://git.openstreetmap.org/dns.git/blob/HEAD:/bandwidth/tile.openstreetmap.yml
>>
>> Sinta-se à vontade para entrar em contato comigo se preferir.
>>
>> Atenciosamente,
>>
>> Grant
>>
>> - - - - - - - - - - - - - - - - - - - -
>>
>>
>> On Tue, Feb 19, 2019 at 5:16 PM Grant Slater 
>> wrote:
>>
>>> Hi OpenStreetMap Talk-BR,
>>>
>>> (Please would someone kindly translate this into Portugês?)
>>>
>>> Quick Introduction: I am part of the volunteer Operations team who run
>>> the OpenStreetMap.org servers.
>>>
>>> Our tile.openstreetmap.org CDN would greatly benefit from having a
>>> cache server in Brazil.
>>> It would make the default rendered map on OpenStreetMap.org much
>>> faster for Brazilians.
>>>
>>> The live CDN Country -> Edge Cache Mapping:
>>> https://dns.openstreetmap.org/tile.openstreetmap.org.html
>>>
>>> Know anyone who could help?
>>> We're ideally looking for a dedicated physical server or powerful VM
>>> with 8GB+
>>> RAM and at least 146GB of storage.
>>> More details here: https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN
>>>
>>> Our current peak Brazil traffic is currently around 70,000,000 bits per
>>> second.
>>>
>>> Full breakdown here in bits per second:
>>>
>>> https://git.

Re: [Talk-br] Able to host a tile.osm.org CDN node? (Inglês)

[Peter Krauss]

- - - Tradução do e-mail (fw anexo) do Grant:  - - -

Olá OpenStreetMap Talk-BR,

Introdução rápida: faço parte da equipe voluntária de Operações
   https://wiki.osmfoundation.org/wiki/Operations_Working_Group
a qual mantém os servidores do OpenStreetMap.org rodando.

Nosso servidor CDN (Rede de Fornecimento de Conteúdo)
   tile.openstreetmap.org
seria muito beneficiado por ter um servidor de cache no Brasil.
Isso tornaria o mapa renderizado padrão do site OpenStreetMap.org
mais rápido para os brasileiros.

Veja como estão hoje as conexões da rede CDN por país,
  The live CDN Country -> Edge Cache Mapping:
  https://dns.openstreetmap.org/tile.openstreetmap.org.html

Conhece alguém que possa ajudar?
Estamos procurando idealmente um servidor físico dedicado ou VM poderosa
com 8 GB ou + de RAM e pelo menos 146 GB de armazenamento.
Mais detalhes em
  https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN

Nosso atual pico de tráfego no Brasil é atualmente de cerca
de 70.000.000 bits por segundo.

Discriminação completa, em bits por segundo:

https://git.openstreetmap.org/dns.git/blob/HEAD:/bandwidth/tile.openstreetmap.yml

Sinta-se à vontade para entrar em contato comigo se preferir.

Atenciosamente,

Grant

- - - - - - - - - - - - - - - - - - - -


On Tue, Feb 19, 2019 at 5:16 PM Grant Slater 
wrote:

> Hi OpenStreetMap Talk-BR,
>
> (Please would someone kindly translate this into Portugês?)
>
> Quick Introduction: I am part of the volunteer Operations team who run
> the OpenStreetMap.org servers.
>
> Our tile.openstreetmap.org CDN would greatly benefit from having a
> cache server in Brazil.
> It would make the default rendered map on OpenStreetMap.org much
> faster for Brazilians.
>
> The live CDN Country -> Edge Cache Mapping:
> https://dns.openstreetmap.org/tile.openstreetmap.org.html
>
> Know anyone who could help?
> We're ideally looking for a dedicated physical server or powerful VM with
> 8GB+
> RAM and at least 146GB of storage.
> More details here: https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN
>
> Our current peak Brazil traffic is currently around 70,000,000 bits per
> second.
>
> Full breakdown here in bits per second:
>
> https://git.openstreetmap.org/dns.git/blob/HEAD:/bandwidth/tile.openstreetmap.yml
>
> Feel free to contact me off-list if you prefer.
>
> Kind regards,
>
> Grant
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

(*oops* desculpem dei Enter ... pronto agora no computador tela grande)

O nó da questão, que invalidada ou não seus argumentos, e nos forçaria a
recomeçar do zero a discussão,
está na sua afirmação incompleta de que
*   "(...) constatamos que a projeção dos endereços nas ruas cerca de 5% de
endereços errados (...)"*

Exagerando, é como usar algoritmo de Bubble Sort
<https://en.wikipedia.org/wiki/Bubble_sort> para afirmar que a ordenação
por computador é coisa ruim,
ou *pegar dados sem filtrar e dizer que os dados estão ruins*...

Todo algoritmo de importação bem feitinho tem critério objetivo de
filtragem, tem um "nível de descarte" que fica meio informal na receita
complementar que chamamos de *metodologia*,  já que em geral o computador
não pode avaliar sozinho, precisa do parecer final do humano em vários
passos...
Alias podemos dizer que a *metodologia assistida é a única válida*, o
acompanhamento humano é uma é uma obrigação (*pelas normas OSM
<https://wiki.openstreetmap.org/wiki/Import>).  *

Resumindo o que talvez seja um posicionamento pessoal, convém conferir se
alguém concorda:

*  a métrica de erros para fazer sentido nas nossas discussões precisa ser
da metodologia assistida, não do algoritmo sozinho.

* não se pode afirmar que "importação é coisa ruim", o que se pode afirmar
é que "a metodologia X com o algoritmo Y para os dados Z é ruim".. Até que
se prove o contrário.





On Thu, Feb 14, 2019 at 4:20 PM Fernando Trebien 
wrote:

> On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss  wrote:
> > 2.2. Ponto oficial incompleto: pode ser importando?  Essa é a discussão.
> As fontes de informação na verdade existem, só que não é uma fonte única,
> pode estar misturando verdade de campo, norma oficial (por exemplo leis de
> nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
> prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
> pessoas do OSM terão tempo e capacidade de avaliar.  ESTÁ EM DISCUSSÃO, mas
> precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no
> "ponto oficial completo" (2.1 acima).  Mesmo depois de discutir e chegar a
> um consenso aqui precisaremos verificar com restante da comunidade OSM.
> >
> > 2.2.1. Com  numeração (addr:housenumber) obtida por
> interpolação/proximidade.
>
> Acho que depende das características do dado original. Se o que ele
> tem é o endereço inicial e final de cada quadra, ou um endereço no
> meio de cada quadra, ele pode ser importado sem problema algum usando
> linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns
> outras cidades do mundo, contanto que os pontos de endereço contenham
> o nome da rua. Seria indesejável interpolar o endereço gerando cada
> ponto intermediário.
>
> > 2.2.2. Com  nome de rua (addr:street) obtido por proximidade.
>
> Entre poder/não poder eu prefiro responder isso com as consequências
> pro OSM de importar com ou sem um tratamento dos problemas dessa
> abordagem.
>
> Em Porto Alegre já constatamos que a projeção dos endereços nas ruas
> para obter o nome da rua produz cerca de 5% de endereços errados, ou
> seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui
> qualidade suficiente para suportar satisfatoriamente um serviço de
> geocodificação. Se, por exemplo, alguém quiser usar o  mapa para
> oferecer um serviço de entregas ou de transporte individual, muitos
> endereços estarão a quilômetros de distância do local correto, o que
> obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso,
> eu esperaria que o usuário simplesmente descartaria o OSM e adotaria
> um concorrente, como o Google Maps. Pior do que isso, se alguém quiser
> usar os endereços existentes para inserir pontos de interesse a partir
> de uma listagem local, os erros serão propagados e a correção exigirá
> mais esforço (talvez o dobro) do que se tivesse sido feita antes.
>
> Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses
> problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a
> pena considerando o benefício. Na maioria dos municípios (em geral
> pequenos) um trabalho desse tipo poderia ser feito completamente em
> poucas horas.
>
> Onde não houver mão-de-obra disposta a realizar a correção, acho que é
> fundamental no mínimo documentar (de preferência no wiki) que ficou
> pendente de correção, do contrário ninguém vai saber onde procurar os
> erros. Idealmente seria aberta também uma tarefa em algum sistema de
> gestão de tarefas para orientar e monitorar esse trabalho. Agora que
> temos o Kaart interessado em nos ajudar, podemos também tentar um
> contato com eles para que realizem as correções manualmente. Se este
> caso surgir com frequência em municípios diferentes, acho que vale a
&g

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

O nó da questão, que invalidada ou não seus argumentos, e nos forçaria a
recomeçar do zero a discussão,
está na sua falsa afirmação de que *"Em Porto Alegre já constatamos que a
projeção dos endereços nas ruas*
*para obter o nome da rua produz cerca de 5% de endereços errados"*

On Thu, Feb 14, 2019 at 4:20 PM Fernando Trebien 
wrote:

> On Thu, Feb 14, 2019 at 7:55 AM Peter Krauss  wrote:
> > 2.2. Ponto oficial incompleto: pode ser importando?  Essa é a discussão.
> As fontes de informação na verdade existem, só que não é uma fonte única,
> pode estar misturando verdade de campo, norma oficial (por exemplo leis de
> nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
> prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
> pessoas do OSM terão tempo e capacidade de avaliar.  ESTÁ EM DISCUSSÃO, mas
> precisamos primeiro arrumar a casa, chegar a uma descrição satisfatória no
> "ponto oficial completo" (2.1 acima).  Mesmo depois de discutir e chegar a
> um consenso aqui precisaremos verificar com restante da comunidade OSM.
> >
> > 2.2.1. Com  numeração (addr:housenumber) obtida por
> interpolação/proximidade.
>
> Acho que depende das características do dado original. Se o que ele
> tem é o endereço inicial e final de cada quadra, ou um endereço no
> meio de cada quadra, ele pode ser importado sem problema algum usando
> linhas interpoladoras, tal como se faz sem Buenos Aires e em alguns
> outras cidades do mundo, contanto que os pontos de endereço contenham
> o nome da rua. Seria indesejável interpolar o endereço gerando cada
> ponto intermediário.
>
> > 2.2.2. Com  nome de rua (addr:street) obtido por proximidade.
>
> Entre poder/não poder eu prefiro responder isso com as consequências
> pro OSM de importar com ou sem um tratamento dos problemas dessa
> abordagem.
>
> Em Porto Alegre já constatamos que a projeção dos endereços nas ruas
> para obter o nome da rua produz cerca de 5% de endereços errados, ou
> seja, 1 erro em cada 20 endereços. Um dado com tantos erros não possui
> qualidade suficiente para suportar satisfatoriamente um serviço de
> geocodificação. Se, por exemplo, alguém quiser usar o  mapa para
> oferecer um serviço de entregas ou de transporte individual, muitos
> endereços estarão a quilômetros de distância do local correto, o que
> obviamente seria bem ruim pra confiabilidade do serviço. Nesse caso,
> eu esperaria que o usuário simplesmente descartaria o OSM e adotaria
> um concorrente, como o Google Maps. Pior do que isso, se alguém quiser
> usar os endereços existentes para inserir pontos de interesse a partir
> de uma listagem local, os erros serão propagados e a correção exigirá
> mais esforço (talvez o dobro) do que se tivesse sido feita antes.
>
> Mesmo numa cidade do tamanho de Porto Alegre, a solução manual desses
> problemas exigiria um trabalho contínuo de ~2 semanas eu acho. Vale a
> pena considerando o benefício. Na maioria dos municípios (em geral
> pequenos) um trabalho desse tipo poderia ser feito completamente em
> poucas horas.
>
> Onde não houver mão-de-obra disposta a realizar a correção, acho que é
> fundamental no mínimo documentar (de preferência no wiki) que ficou
> pendente de correção, do contrário ninguém vai saber onde procurar os
> erros. Idealmente seria aberta também uma tarefa em algum sistema de
> gestão de tarefas para orientar e monitorar esse trabalho. Agora que
> temos o Kaart interessado em nos ajudar, podemos também tentar um
> contato com eles para que realizem as correções manualmente. Se este
> caso surgir com frequência em municípios diferentes, acho que vale a
> pena organizar um grupo de trabalho para fazer as correções manuais.
> Um grupo especializado assim estaria familiarizado com o tipo de erro
> desse processo e poderia trabalhar rápido e com menos erros humanos.
>
> Caso a etapa de documentar a correção não for feita, o resultado mais
> provável é que os erros permanecerão no mapa por um bom tempo e que
> serão esquecidos, prejudicando a confiabilidade dos dados. Por
> exemplo, na importação dos edifícios em Porto Alegre, uma informação
> foi colocada na etiqueta description, foi solicitado aos mapeadores
> que fosse convertida em etiquetas consumíveis (geralmente amenity=*),
> mas esse trabalho nunca foi feito por ninguém. A informação está lá no
> OSM, parada há anos, sem usufruto pelas aplicações. Como diz o wiki
> [2] num texto proveniente do original em inglês, "nunca suponha que
> essas pessoas vão alegremente arrumar a bagunça que você fez."
>
> Não estou dizendo que é obrigação de quem importa fazer a correção
> manual. O importante é traçar um plano de correção e engajar as
> pessoas que o executarão, e havendo interessados em fazer i

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

Oi gente, respondendo primeiro ao Fernando depois ao Pedro,

Fernando, a sua colocação é consistente, mas a discussão evoluiu em duas
frentes (2.1 e 2.2 abaixo), e devemos tomar o cuidado de separar com
clareza,
sugiro dar nomes sempre que referir:

1. *Ponto inválido*: não pode existir no mapa OSM um *node* de
endereçamento sem ambos, nome de rua (*addr:street*) e numeração (
*addr:housenumber*).
É "a lei", "o grande consenso" e a boa prática. Evita-se inserir e
pode-se deletar um ponto inválido.
Por favor, *NAO ESTÁ EM DISCUSSÃO*, já foi discutido e é consenso
universal (na comunidade BR e na comunidade internacional)*.*

*2. MÉTODO DE EDIÇÃO E/OU IMPORTAÇÃO DE PONTOS OFICIAIS: *a diferença entre
um dado oficial e um dado empírico é que o dado oficial não tem confirmação
em campo, mas em contrapartida tem um documento ou *declaração oficial do
governo*. Ver https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Oficial


2.1. *Ponto oficial completo*: pode ser importando pois todos os dados
estão presentes (posição, nome e numeração)  e é uma "verdade oficial",
dispensando maiores (precisa de *consistência* naturalmente!) preocupações
com a verdade de campo homologada por usuários OSM potnto a ponto, *basta
amostragem*.
É consenso, estão todos de acordo em fazer importação automática,
queremos apenas UNIFORMIZAR PROCESSOS e a SIMPLIFICAR/PADRONIZAR um pouco
as os relatórios de importação, para que mais pessoas possam ver e
entender,  *auditar sem perder tempo*.

2.2. *Ponto oficial incompleto*: pode ser importando?  Essa é a discussão.
As fontes de informação na verdade existem, só que não é uma fonte única,
pode estar misturando verdade de campo, norma oficial (por exemplo leis de
nomenclatura de rua), dado oficial (ex. os pontos fornecidos pela
prefeitura), etc. O algorítomo mesmo sendo aberto é complexo e poucas
pessoas do OSM terão tempo e capacidade de avaliar.  *ESTÁ EM DISCUSSÃO*,
mas precisamos *primeiro arrumar a casa*, chegar a uma descrição
satisfatória no "ponto oficial completo" (*2.1* acima).  Mesmo depois de
discutir e chegar a um consenso aqui precisaremos verificar com restante da
comunidade OSM
<https://help.openstreetmap.org/questions/67949/how-to-import-address-when-addrstreet-was-obtained-by-inference>
.

2.2.1. Com  numeração (addr:housenumber) obtida por
interpolação/proximidade.
2.2.2. Com  nome de rua (addr:street) obtido por proximidade.

O que acha?  *Podemos seguir com essa terminologia? *importação de "ponto
invalido" (obviamente invalida), de "ponto oficial completo" e de "ponto
oficial incompleto".

- - -

Pedro, quanto ao uso do inglês, a grande maioria não se sente a vontade
para entrar num debate com os gringos da comunidade OSM internacional,
damos a cara para bater sozinhos e em geral saímos de olho roxo por falta
de mais gente apoiando nossa opinião ou escrevendo em melhor inglês o nosso
posicionamento (em geral trazido/traduzido da comunidade local)... Claro,
quem não se importa ou já se sente a vontade deve continuar,
mas a maioria precisa de apoio, e um apoio seu, mesmo usando tradutor,
seria bem-vindo (!)... Se surgir alguma discussão relevante aviso aqui.





On Wed, Feb 13, 2019 at 3:35 PM Fernando Trebien 
wrote:

> Não acho certo importar dados em que addr:street tenha sido inferida
> por qualquer método sem que tenha sido feita uma conferência antes de
> fazer a importação. Daí se está importando sujeira no mapa que tende a
> ser esquecida e a prejudicar a qualidade final dos dados. O certo é
> definir uma forma de tratar as incorreções, seja aprimorando o método,
> usando métodos suplementares, ou fazendo uma revisão manual antes. É
> que estamos fazendo em PoA e em Curitiba, e não acho que devam ser
> abertas exceções.
>
> É justamente pra evitar que sejam importadas grandes quantidades de
> dados incorretos que existe todo esse protocolo de elaborar uma
> proposta e aprovar pela comunidade. Senão, qualquer um podia importar
> qualquer coisa (legalizada) de qualquer jeito. Inclusive, isso consta
> nos guidelines de importação. [1][2]
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Take_great_care_to_avoid_damaging_the_database
> [2]
> https://wiki.openstreetmap.org/wiki/Pt:Import/Guidelines#N.C3.A3o_estrague_os_dados.21
>
> On Tue, Feb 12, 2019 at 5:09 PM Peter Krauss  wrote:
> >
> > Otima dica Adriano (!), que  tal então a seguinte regra para os
> algoritmos de inferência de street:
> >
> > * quando a inferência for altamente confiável, aplicar apenas tag note,
> https://wiki.openstreetmap.org/wiki/Key:note
> > com um valor padronizado, algo como "addr:street:inferred".
> >
> > * quando a inferência for mais fraca ou carecer de avaliação estatística
> de confiabilidade, usar a tag fixme,
> > https://wiki.openstr

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

Otima dica Adriano (!), que  tal então a seguinte regra para os algoritmos
de inferência de street:

* quando a inferência for *altamente confiável*, aplicar apenas tag *note*,
https://wiki.openstreetmap.org/wiki/Key:note
com um valor padronizado, algo como "addr:street:inferred".

* quando a inferência for mais fraca ou carecer de avaliação estatística de
confiabilidade, usar a tag *fixme*,
https://wiki.openstreetmap.org/wiki/Key:fixme
   para relatar a mesma coisa,  algo padronizado como
"addr:street:inferred_low_reliability".

É esperado que quem for editar, na maior parte dos casos, precisa apenas
remover a tag note ou fixme, homologando humanamente a informação (de
preferencia com alguma evidência de campo). O que acham, o caminho é esse?





On Tue, Feb 12, 2019 at 2:00 PM Adriano Rosa  wrote:

> sugiro que seja adicionada alguma etiqueta (fixme ou note) para indicar
> que falta adicionar o nome da rua no endereço.
>
> assim se evita que novos mapeadores achem que o jeito certo é somente
> adicionar o número e fica o registro que falta dado.
>
> cordialmente,
>
> adriano.
>
> _
> Sempre tenha os seus arquivos quando você precisar deles com @Dropbox.
> Conta
> de 2GB é grátis!
>
> Acesse: http://db.tt/enaEb5F
>
>
>
>
> On Tue, Feb 12, 2019 at 1:24 PM Peter Krauss  wrote:
>
>> Pedro, são mais argumentos a favor e concordo, mas a favor do que não
>> seria uma boa prática... A boa prática é já registrar o ponto com o nome de
>> rua, mas aí não seria o nome 100% certo, seria inferido por presunção de
>> proximidade com a rua...
>>
>> O que se comentou de saída para o dilema, que requer apoio na comunidade
>> geral do OSM, é estabelecer regras claras e consensuais para essa
>> presunção, e adicionalmente incluir uma tag de alerta "esse nome foi
>> inferido por computador" (tal como já fazemos com número de porta inferido
>> por interpolação).
>>
>> ... Quando  comento "requer apoio na comunidade geral do OSM", é
>> fundamental, precisamos comparecer em bando, pois senão quem for atrás só
>> vai perder tempo e se queimar, como já ocorreu outras fazes: se a
>> comunidade-Brasil não começar a se portar como "autoridade do Brasil", a
>> OSMF e pessoal de outros países, que desconhecem nossa realidade, vão
>> continuar passando por cima, e nossas demandas continuarão "à margem"...
>> Você escreve em inglês?  Alguém aqui poderia apoiar uma discussão  em
>> inglês?
>>
>>
>>
>> On Tue, Feb 12, 2019 at 12:30 PM Pedro vida torta <
>> pedrovidator...@gmail.com> wrote:
>>
>>> Não vejo grandes problemas e importar sem o nome da via, teremos erros
>>> em esquinas que podem ser corrigidos com o tempo, a maioria dos aplicativos
>>> mostra a numeração no mapa e mesmo com o erro qualquer usuário pode achar
>>> visualmente, no caso em questão somente a numeração esta disponível e eu
>>> ficaria extremamente satisfeito com isso , já que colocar depois o nome da
>>> via depois e bem mais fácil.
>>>
>>> Em sex, 8 de fev de 2019 às 09:56, Sérgio V. 
>>> escreveu:
>>>
>>>> Trago aqui questão levantada,
>>>> da necessidade (ou não) de ter addr:street:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>>>>
>>>> (esta questão é muito importante para esta e quaisquer outras
>>>> importações do tipo de "endereços")
>>>>
>>>> -Levantada a questão de que:
>>>> "para um endereço ser localizado no OSM, precisa ter ainda
>>>> addr:street=*".
>>>>
>>>> -Problema:
>>>> Nos dados originais não tem registrado nome da rua.
>>>> O que pode ser obtido do original é: addr:housenumber=* + coordenadas.
>>>>
>>>> Necessidade (teórica ou real?): teria que complementar (adicionar)
>>>> addr:street=* para todos os 200.000 nós. (?!?)
>>>>
>>>> Dúvidas: Isso vale para qualquer endereço, para que possa ser
>>>> localizado?
>>>>
>>>> Possibilidades de executar:
>>>> a) automatizado: gerando e adicionando valores de "nome de rua" por
>>>> análise de proximidade aos pontos: pode gerar erros;
>>>> b) manualmente: adicionando valores de "nome de rua" (preciso).
>>>>
>>>> Objeções:
>>>>
>>>> -É possível "retornar" o "nome de rua" por busca? Como com análise de
>>&g

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

Pedro, são mais argumentos a favor e concordo, mas a favor do que não seria
uma boa prática... A boa prática é já registrar o ponto com o nome de rua,
mas aí não seria o nome 100% certo, seria inferido por presunção de
proximidade com a rua...

O que se comentou de saída para o dilema, que requer apoio na comunidade
geral do OSM, é estabelecer regras claras e consensuais para essa
presunção, e adicionalmente incluir uma tag de alerta "esse nome foi
inferido por computador" (tal como já fazemos com número de porta inferido
por interpolação).

... Quando  comento "requer apoio na comunidade geral do OSM", é
fundamental, precisamos comparecer em bando, pois senão quem for atrás só
vai perder tempo e se queimar, como já ocorreu outras fazes: se a
comunidade-Brasil não começar a se portar como "autoridade do Brasil", a
OSMF e pessoal de outros países, que desconhecem nossa realidade, vão
continuar passando por cima, e nossas demandas continuarão "à margem"...
Você escreve em inglês?  Alguém aqui poderia apoiar uma discussão  em
inglês?



On Tue, Feb 12, 2019 at 12:30 PM Pedro vida torta 
wrote:

> Não vejo grandes problemas e importar sem o nome da via, teremos erros em
> esquinas que podem ser corrigidos com o tempo, a maioria dos aplicativos
> mostra a numeração no mapa e mesmo com o erro qualquer usuário pode achar
> visualmente, no caso em questão somente a numeração esta disponível e eu
> ficaria extremamente satisfeito com isso , já que colocar depois o nome da
> via depois e bem mais fácil.
>
> Em sex, 8 de fev de 2019 às 09:56, Sérgio V. 
> escreveu:
>
>> Trago aqui questão levantada,
>> da necessidade (ou não) de ter addr:street:
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>>
>> (esta questão é muito importante para esta e quaisquer outras importações
>> do tipo de "endereços")
>>
>> -Levantada a questão de que:
>> "para um endereço ser localizado no OSM, precisa ter ainda addr:street=*".
>>
>> -Problema:
>> Nos dados originais não tem registrado nome da rua.
>> O que pode ser obtido do original é: addr:housenumber=* + coordenadas.
>>
>> Necessidade (teórica ou real?): teria que complementar (adicionar)
>> addr:street=* para todos os 200.000 nós. (?!?)
>>
>> Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado?
>>
>> Possibilidades de executar:
>> a) automatizado: gerando e adicionando valores de "nome de rua" por
>> análise de proximidade aos pontos: pode gerar erros;
>> b) manualmente: adicionando valores de "nome de rua" (preciso).
>>
>> Objeções:
>>
>> -É possível "retornar" o "nome de rua" por busca? Como com análise de
>> proximidade? Os aplicativos podem operar assim? Isso não pode deixar para
>> ser feito pelos aplicativos de localização/navegação, sob demanda? Se isso
>> for possível, não necessitaria adicionar valor de "nome de rua", nem
>> manualmente, nem automatizadamente. Simplesmente não adicionar
>> addr:street.
>>
>> -Se for real a "necessidade indispensável" de ter que constar ou
>> "adicionar" addr:street=* a cada nó importado de addr:housenumber=* (mesmo
>> onde não haja no original), então vai certamente inviabilizar inúmeras
>> possibilidades de importações de endereços.
>>
>> -Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco -
>> esqueça-se, eu não faço; outros se quiserem peguem os dados ali
>> disponibilizados e continuem.
>> De todo modo, certamente inviabiliza maior parte de futuras importações
>> em outros locais.
>>
>> - - - - - - - - - - - - - - - -
>>
>> Sérgio - http://www.openstreetmap.org/user/smaprs
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
>
> --
> *Pedro Esmerilho*
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

Oi Nelson, se formos pelo caminho do OpenAddresses, seria preciso de uma
tag de acurácia ou confiabilidade, ou um simples boolean indicando que
street foi inferida.
... Sem essa informação fica realmente um monte de dado "no limbo", em
utilidade,
Ver discussão   https://github.com/openaddresses/openaddresses/issues/4238



On Fri, Feb 8, 2019 at 1:06 PM Nelson A. de Oliveira 
wrote:

> Pegando um outro projeto https://openaddresses.io/
>
> Nele existe obrigatoriedade de número e nome de rua (senão não se
> forma um endereço)
>
> https://github.com/openaddresses/openaddresses/blob/master/CONTRIBUTING.md#attribute-tags
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Proposta de Importação de endereços SMF/PMPA

[Peter Krauss]

PARABENS Sergio!

Não é uma tradição, mas convém solicitar que aqueles que participam em
geral deste fórum, que deem seu *voto*...

Na Wiki

o Sergio também esclareceu o processo em lote com figuras e detalhes
técnicos, ou seja,
*está transparente o que será feito no piloto automático*, e temos plena
confiança no "piloto do piloto automático", que é o Sergio.

Por mim, APROVADISSIMO!

- - -
PS: fica a sugestão de importar como CC0, se é que existe essa
possibilidade.


On Thu, Feb 7, 2019 at 5:12 PM Sérgio V.  wrote:

> Prezados/as,
>
> Envio aqui para avaliação da comunidade a documentação formalizada da
> Proposta de "Importação da camada de numeração de endereços da PMPA",
> conforme dados disponibilizados pela SMF/PMPA (Secretaria da
> Fazenda/Prefeitura Municipal de Porto Alegre).
>
> A proposta integral está documentada na seguinte página wiki, para
> avaliação:
>
> https://wiki.openstreetmap.org/wiki/Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>
> Contém:
> -descrição da proposta;
> -documentação legal;
> -descrição dos procedimentos de exame, conversão, separação de conflitos
> encontrados, validação do material para importação;
> -listagem do material finalizado, preparado para importação;
> -links (ao final da página), para baixar os arquivos, para exames:
> 1) ZIP com os arquivos dos resultados finais em .osm 
> (SMF-RESULTADOS-FINAIS-OSM.zip
> 4,6MB), contendo:
> -OBJETOS VALIDADOS, preparados para importação:
>05 arquivos .osm  =  199.614 objetos (nós)
> -OBJETOS REMOVIDOS, com quaisquer conflitos, separados para
> avaliação caso-a-caso:
>03 arquivos .osm  = 6.444  objetos (nós)
> Total de objetos em .osm = 206.058
> 2) ZIP com os arquivos dos dados integrais originais
> (SMF-XLSX-ORIGINAIS.zip 55MB) ;  total original = 206.061 objetos
> (03 objetos destes 206.061 originais foram excluídos de início, cf.
> documentado na wiki: 01 objeto não importado por coordenada inválida, e
> 02 objetos removidos de início por campos nulo e inválido.)
>
> Apresento para avaliação da comunidade. A proposta pode ser alterada se
> necessário.
>
> (comentários podem ser na página de discussão da mesma wiki:
>
> https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>  )
>
> Creio que a importação pode suceder em cerca de 05 changesets para os
> validados. Ao menos estes 199.614 objetos validados (em 05 arquivos .osm)
> estão a princípio prontos para importação imediata ao OSM, em sendo
> aprovada a proposta.
> Os demais 6.444 separados por não validação necessitam de avaliação
> caso-a-caso, por conflitos diversos entre si e com o existente no OSM.
>
> Peço considerar um prazo inicial proposto de 2 semanas a partir da
> presente data para avaliações e considerações.
> Após o que, se não houver outras considerações ou alterações necessárias,
> propõe-se considerar apto à importação o material indicado como validado.
>
> Atenciosamente e à disposição,
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> 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-ie] Official Launch of OSGeoIE 2019 - The 3rd Irish OSGeo Local Chapter Symposium - 11th April 2019 - Cork

[Peter Mooney]

Hello everyone,

Apologies in advance for any unintended cross-posting and duplication of
this email.

We are delighted to now officially launch OSGeoIE 2019 (the 3rd annual
Irish Local Chapter OSGeo Symposium) which will be held at the Metropole
Hotel in Cork City on Thursday 11th April 2019. This follows on from our
very successful inaugural event in Limerick in May 2017 and in Portlaoise
last May 2018.

There will be a few small changes and improvements this year. We'll be
announcing a student-focused Poster competition. We've also introduced a
student-friendly priced ticket which will remain the same price right up to
the event. We'll also be expanding our sponsorship options.

We're also very excited to announce three workshops at the symposium: An
Introduction to GC2, An Introduction to OpenStreetMap (by OSM Ireland) and
Geospatial Python.

In particular we are very happy to welcome the OSM Ireland community to our
symposium. As discussed at the launch of OSM CLG in Maynooth in October
2018 there are many opportunities and advantages to synergies and
collaborations between our two communities.

The symposium homepage is on the OSGeo Wiki at [1].

You'll find student (€40) and early bird (€60) tickets onsale at [2].

You'll find the Call for Participation (to give a lightning talk) at [3].
The deadline for these short submissions is March 22nd 2019. The OSGeoIE
symposium invites anyone using OSGeo and FOSS4G tools in Ireland to tell
the community about their experiences, innovations etc. The symposium
maintains a relaxed and informal atmosphere.

We'll be tweeting on @OSGeoIE.

We're very much looking forward to the event and your participation.
Lightning talks on how you're using OSGeo and FOSS4G tools to work with OSM
are particularly welcomed.

May the FOSS be with you.

Peter (on behalf of the OSGeoIE Local Organising Committee)

[1] https://wiki.osgeo.org/wiki/Ireland/Symposium2019
[2]
https://www.eventbrite.ie/e/osgeoie-the-3rd-irish-osgeo-symposium-2019-tickets-55405236554
[3] https://goo.gl/forms/YOEZ0Ku4jkl6h8bC2
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-br] Parceria OSM e ANA

[Peter Krauss]

Thierry, parabéns!  Importantíssimo ter alguém da OSM Brasil abrindo esses
canais.

Santamariense, concordo quanto aos nomes... Acho que é de fato um primeiro
passo para a ANA mostrar um mínimo de boa vontade, faz anos que pedi (mas
não insisti) uma simples planilha com nomes dos comitês de bacia... Ainda
hoje é uma zona, ninguém diz quais são os códigos (siglas) oficiais nem diz
qual lista está completa... Sugiro pedir os dados oficiais básicos sobre os
comitês de bacias,

http://datasets.ok.org.br/cbh-codes




On Thu, Jan 10, 2019 at 1:17 AM santamariense  wrote:

> > Podemos pensar em uma proposta de os colaboradores da plataforma nos
> auxiliarem na identificação da toponímia dos cursos d’água e massas d’água
> de nossas bases da ANA
>
> Interessante que boa parte dos cursos d'água tem diferentes nomes a
> depender da fonte (órgão governamental), e se for a campo conferir,
> principalmente nas zonas rurais, os moradores nem sabem que tem nome,
> chamando apenas de "sanga", "rio", -- Não é por acaso que até órgãos
> governamentais tem dificuldade para identificá-los e muitas vezes
> identificam determinado curso d'água com nome diferente do
> identificado por outro órgão, ou mesmo com traçado diferente,
> principalmente em ponto próximos a nascentes onde tem vários braços e
> não se sabe qual deles leva o nome.
>
> Tem alguma ideia de como poderia desenhar essa possível parceria?
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Peter Krauss]

Parabéns @Santamariense!  É por aí, tentado, insistindo e automatizando o
que for possível!

Já dá para esboçar uma ótima receita de bolo: podemos documentar e
aperfeiçoar seu algoritmo na Wiki, sugiro esse link, onde já copiei/colei
suas descrições:

https://wiki.openstreetmap.org/wiki/Brasil/Metodologia/Importa%C3%A7%C3%A3o_de_endere%C3%A7os

se complementar postando imagens ilustrativas de cada passo, como sugere o
Sergio, será otimo e todos poderemos aperfeiçoar a documentação e o método
na Wiki.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-de] Erinnerung an den fristgerechten OSMF-Beitritt für die OSMF-Vorstandswahl

[Peter Barth]

Hi,

ich habe ihm geantwortet.
(Inhalt aus Datenschutz nur an ihn)

Gruß,
Peda

Sven Geggus schrieb:

> Michael Reichert  wrote:
> 
> > Aktuelle Mitgliederstatistik (ohne ausgelaufene und noch nicht gültige
> > [1] Mitgliedschaften)
> 
> Wie kann man denn prüfen ob seien Mitgliedschaft noch gültig ist?
> 
> Ich hasse das. Andere Vereine buchen einfach über SEPA Lastschrift ab und
> gut iss.
> 
> Könnte nicht der FOSSGIS als local chapter sowas für deutsche Mitglieder
> übernehmen?
> 
> Gruss
> 
> Sven
> 
> -- 
> Das Internet wird vor allem von Leuten genutzt, die sich Pornografie
> ansehen, während sie Bier trinken, es ist daher für Wahlen nicht
> geeignet (Jaroslaw Kaczynski)
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org

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

Re: [Talk-at] OSM Wochennotiz Aktualität & Richtigstellung

[Peter Barth]

Hi,

grubernd schrieb:
> allerdings schliesse ich mich gedanklich trotzdem denen an, die sagen 
> eine wöchentliche Zwangsbeglückungserinnerung für ein wöchentliches 
> Ereignis ist übertrieben. sowas können nur Leute mit der 
> Aufmerksamkeitsspanne eines facebook-teenagers einfallen. zumal diese 
> Mail ja nicht einmal den Inhalt wiedergibt und somit auch für Suchen 
> komplett sinnlos ist. einmal im Quartal eine zusammenfassende Erinnerung 
> sollte für alte und neue Mitglieder der Mailingliste ausreichen.

die Idee war da eher, dass die WN rauskommt wenn sie fertig ist und
nicht an einem fixen Tag. Daher macht die Erinnerung auch irgendwo Sinn.

Ich benutze auch lieber RSS (scheint aber irgendwie auszusterben), aber
dafür hatten wir ja eine kleine nichtrepräsentative Umfrage auf dieser
ML gemacht und da war die Mehrheit für die Erinnerungsmail. Ich glaube
keiner im WN-Team verspürt den Zwang die Mail zu schicken, aber nur
wegen einiger lauter Stimmen sollte sie nicht unterlassen werden solang
die Mehrheit die Erinnerung wünscht. (Nur zur Erklärung, nicht um dir zu
widersprechen :-))

Gruß.
Peda


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