Re: [Talk-de] mobiler Zielgruppen-spezifischer Editor

[Markus]

Hallo Gisbert,

> Ich hoffe, das was ich schrieb war verständlich

Ich bin beeindruckt von Eurer tollen Arbeit!

Um solche Zielgruppen zu untertützen bräuchte OSM ein ganz simples Tool,
das auf jedem Handy simpel installiert werden kann, und genau die für
die Zielgruppe erforderlichen "tags" anbietet (hier
Motorrad-Parkplätze). Idealerweise mit Benutzerführung. [1]

Das Tool müsste ebenso simpel konfigurierbar sein (hier z.B. durch
Gisbert), damit man es für die Zielgruppe "individualisieren" kann.

Damit jeder - auch diejenigen die keine OSMer werden wollen -
beitragen kann :-)

Gibt es so etwas schon?

Mit herzlichem Gruss,
Markus

[1] Benutzerführung
Stelle dich auf den Parkplatz und drücke auf den Button "Koordinate".
Gib im Feld "Anzahl" die Zahl der maximal verfügbaren
Motorrad-Parkplätze an.
Gib im Feld "Adresse" Strasse, Haus-Nr, Ort, PLZ, Land ein.
Beschreibe im Feld "Beschreibung" die genaue Lage des Parkplatzes,
und ob es da sonst noch etwas Erwähnenswertes gibt (Restaurant Kiosk,
Fastfood, Eisdiele, Rastplatz, Brunnen, Toilette, Unterstand,
Aussichtspunkt, etc).
Mache ein Foto.
Klicke auf "Absenden".
(oder ähnlich...)

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

[Talk-it] problema rendering mappe su alcuni punti di interesse

[Marco Bartalini]

Ragazzi, sto provando ad inserire un punto di interesse: in pratica è una
pietra tondeggiante dovuta ad erosione (marmitta del gigante) che è un bel
punto di interesse da far vedere nella zona... Mi sa che sbaglio tag perchè
non riesco a farlo visualizzare sulle mappe... mi potreste suggerire un tag
da utilizzare?

questo è il punto http://www.openstreetmap.org/#map=19/40.08952/18.49638

grazie



*Marco Bartalini,marcobartal...@gmail.com *
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] GB Coastline - PGS vs OS

[Jason Woollacott]

Colin,


I've been doing some coastline updates around the South West, and have been 
basing my coastline on the OS_StreetView map layer which also shows MHW.  
however the GPX file does not seem to match this.   In Cornwall, which has a 
very jagged coast, you can never rely on Bing as the angles are quite often 
wrong,  but on flatter ground, say around, Looe, 
https://www.openstreetmap.org/#map=17/50.35216/-4.44840

The GPX around the pier goes well into the sea (about 6m), compared to the OS 
SV layer which links fairly close to the bing image at that point.


Agreed that the coastline extract is much better than the PGS, which is a still 
straight lines in some places.  however, one other area that the GPX extract 
doesn't seem to cover is the islet and rocks which are above sea level even at 
high water level.  (See the Looe link again)


Jason (Unieagle)







From: David Groom 
Sent: 12 December 2016 00:51
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] GB Coastline - PGS vs OS

Colin

I was more talking about the actual shape of the MHW rather than its position; 
if that makes sense.

some examples of problems in the Isle of Wight

1)  There's a section here  
http://www.openstreetmap.org/#map=17/50.66636/-1.48566, where the Bing imagery 
seems reasonably aligned to the gps tracks of the main road, but the gpx file 
for MHW seems to be too far to the north on the cliff area, and too far to the 
south on the area to the east.  this beach shelves relatively steeply so there 
is unlikely to be much difference between MHWS & MHWN

2) Even clearer is an area 
http://www.openstreetmap.org/#map=17/50.69439/-1.09414, OSM is much more 
accurate here than the OS Boundary Line

3)  The car park and ice rink here 
http://www.openstreetmap.org/#map=18/50.73237/-1.15736  were built sometime 
around 1990, but Boundary line  MHW would show these as flooded

4)  More inaccuracies here   
http://www.openstreetmap.org/#map=19/50.76650/-1.30029

David



-- Original Message --
From: "Colin Smale" >
To: talk-gb@openstreetmap.org
Sent: 11/12/2016 22:17:44
Subject: Re: [Talk-GB] GB Coastline - PGS vs OS


Hi David,

Looking at the spot you indicate on Bing imagery does indeed look like MHW 
should be above the salt-marsh areas. Looking at Google[1] it is however 
possible that the grass doesn't quite get submerged, even at the highest tides, 
so it might also be possible that it is strictly correct.

The Bing imagery is of course just a snapshot, and we don't know the state of 
the tide at the moment the photo was taken, so it can also be misleading. Even 
a personal visit is not really enough as MHW is apparently calculated over a 
19-year cycle (not sure if OS use this though) and things could change a lot in 
that time. As MHW is an average, many tides will of course be higher.

The OS data looks a definite improvement for steeper coastlines, where 
combining OS admin boundaries with PGS coastlines produces many anomalies 
(admin boundary=MLW inland of coastline=MHW). I would definitely suggest 
applying the OS MHW data to address this kind of issue. But I agree, use of the 
OS data would need case-by-case judgements. However I still think the OS data 
is probably a better base to work from than (unimproved) PGS for reasons I 
mentioned earlier.

Could you give a couple of examples of problems you saw in the IoW?

//colin



[1] 
https://www.google.com/maps/@51.5386032,0.6292606,3a,24.7y,277.12h,84.08t/data=!3m6!1e1!3m4!1sMl8cwBlLLuOVtPES_DfkOQ!2e0!7i13312!8i6656

On 2016-12-11 22:30, David Groom wrote:

I suspect that even though much of the coastline is tagged "source=PGS" is has 
been amended by reference to Yahoo and after that Bing imagery, but the 
subsequent editors did not remove the "source=PGS" tag.

Certainly comparing your gpx file for the Isle of Wight with the coastline 
currently in OSM there appear a number of places where the gpx file does not 
accurately represent MHW.

I certainly would not want to see a wholesale replacement of what is in 
currently in OSM with OD Boundary Line data.

Looking here http://www.openstreetmap.org/#map=19/51.53546/0.60580 an area near 
Southend, unless the Bing imagery is outdated, the Boundary Line data seems to 
be an odd representation of the coastline.

David
On 11/12/2016 10:43, Colin Smale wrote:

Hi,

Most of the coastline is currently tagged as "source=PGS". As part of the 
Boundary-Line open data set OS provide MHW lines which look to be significantly 
better than the PGS data:

  * Much newer - updated twice a year, although I am not sure how old
the actual underlying survey data is (PGS coastlines seem to be
from 2006)
  * Better resolution - more nodes, smoother curves
  * Consistent with admin boundary data, so MLW never appears above
MHW (often a problem on rocky coastlines like Wales and 

Re: [Talk-us] An actual mini roundabout!

[Greg Morgan]

On Thu, Dec 8, 2016 at 5:36 PM, Rihards  wrote:

> On 2016.12.09. 00:44, Elliott Plack wrote:
> > You mean these things aren't?pasted1
>
> no. here the road is physically making a circle, and you cannot cross
> the middle section - it should be mapped as a separate way, not a single
> node.
>

A long time ago with Potlatch 1, I would not have been able to make these
separate ways.  Thinking back to those days, I like it when knew mappers
use the mini_roundabout to mark the area shown by Elliot.  When I get a
chance, I expand these nodes to a separate way.  I make sure that I keep
the node as apart of the new separate way for history's sake.   I do the
same for mappers that mark a swimming pool with one node.  It gives me a
chance to build on other mapper's work in a positive way.

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

Re: [OSM-talk-ie] Can Townlands be split for Civil parishes and barony boundries?

[Patrick Matthews]

> 4: I think it's just awkwardly shaped.  Not sure if there's a boundary at
> the narrow part or not on
> http://maps.openstreetmap.ie/?zoom=16=53.8103=-9.
> 2563=B00T,
> but I don't see the name for the second townland on the GSGS3906 map if it
> is.
>
> > (4) townland "Lugaphuill" really looks like it should be split in two
> > separate townlands with the same name that border eachother, but it is
> > currently one big townland in OSM. Now the name label (centroid) is in
> > another townland.
> > http://www.openstreetmap.org/#map=16/53.8103/-9.2563=N
>
>
I think the issue there is that there's an inconsistency in the GSGS map -
the
area given for Lugaphuill is 215-2-4 which corresponds to the Lugaphuill in
Drum parish, but the townland has been "merged" with Lugaphuill in Ballyhean
parish (later editions of the 6-inch map give the area as 466-2-24).
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-ie] Can Townlands be split for Civil parishes and barony boundries?

[Patrick Matthews]

To summarize, prior to 1898, townlands could be neatly nested into civil
parishes, poor law
electoral divisions, and baronies, and these three hierarchies were
independent of each
other - but all three in turn nested neatly into counties. Poor law
divisions nested into poor
law unions which could cross county boundaries.

The 1898 Local Government Act meant that:

a) baronies and civil parishes were no longer used as administrative
divisions - though
they were still legally defined entities,
b) poor law unions were divided into urban and rural districts, although
the electoral
division boundaries remained unchanged except where an electoral division
containing
a town was split into a rural and one or more urban electoral divisions.
(Poor law unions
crossing county boundaries were split into rural districts along the county
boundary
line.)
c) some county boundaries were changed, mainly to bring all of a town into
a single
county, but in some cases to move larger chunks of territory (e.g.
Ballaghaderreen)
fromone county to another. These areas, however, remained in the same
baronies
and civil parishes that they previously had been in.

For post-1898 maps:

a) barony boundaries are still shown and townlands are "nested" within them
- so
Curry (Macmanus) should be split,
b) civil parish boundaries are only shown within urban districts,
c) electoral division boundaries are not explicitly shown at all (except
where they
coincide with an urban district boundary) - one consequence of this is that
townlands
which are "split" between two parishes but where both parts are within the
same
electoral division are shown on the map as a single townland,
d) townland boundaries are not shown at all within county boroughs.

My approach in Longford and Cavan has been to treat townlands "crossing"
civil
parish or barony boundaries as separate entities but to distinguish them as
"Townlandname (X civil parish)" and "Townlandname (Y civil parish)".

Regards,

Paddy.

On Sun, Dec 11, 2016 at 10:08 PM, Patrick Matthews 
wrote:

>
> My own opinion would be that townlands shouldn't be split in OSM and if
>> they overlap parishes, then it's up to the software using the OSM data to
>> figure out how to handle them.
>>
>> As far as I understand it, townlands don't necessarily add up to civil
>> parishes, civil parishes don't necessarily add up to baronies and baronies
>> don't necessarily add up to counties.
>
>
> Civil parishes and baronies are independent of each other - one is not a
> subdivision of the other.
>
>
>> Furthermore, townlands don't
>> necessarily add up to electoral divisions.  In rural areas, the GSGS3906
>> map splits the townland into 2 pieces (e.g. Agall (ED Derrycoooly) and
>> Agall (ED Screggan) at
>> http://maps.openstreetmap.ie/?zoom=16=53.26048=-7.59
>> 323=B00T,
>> but in urban areas, it doesn't, it just cuts the ED (and town) boundary
>> through the townland e.g.
>> http://maps.openstreetmap.ie/?zoom=15=52.80303=-6.73
>> 163=B00T.
>> Make of that what you will!
>>
>
> In the Agall example, the townland is "divided" between two civil parishes
> and these two "parts" also
> happen to be in different electoral divisions. After 1898, the civil
> parish boundary was not shown when
> two adjacent "parts" were in the same electoral division.
>
> In the second example, you have a single townland which is spilit between
> an urban and rural electoral
> division (again, before 1898 both the urban and rural portions would have
> formed a single poor law
> electoral division. (As an aside, the mid-20th century editions of the 6
> and 25-inch maps by OSNI
> in Northern Ireland didn't show townland boundaries at all within urban
> districts.)
>
> The original practice of the Ordnance Survey, FWIW, was to treat any
> townland "divided" between two
> civil parishes or two baronies as being two separate townlands. The
> population returns for the 1901 and
> 1911 censuses - after the 1898 Local Government Act - continue to list the
> two "parts" of a townland
> separately even where both lie within the same single electoral division.
>
>
>> Regarding some of your specific issues:
>> 3: I've come across several areas with CPs covering 2 non adjoining areas
>> so this doesn't look that unusual e.g.:
>> http://www.openstreetmap.org/relation/4280429
>> 4: I think it's just awkwardly shaped.  Not sure if there's a boundary at
>> the narrow part or not on
>> http://maps.openstreetmap.ie/?zoom=16=53.8103=-9.256
>> 3=B00T,
>> but I don't see the name for the second townland on the GSGS3906 map if it
>> is.
>>
>> Bear in mind that this is all just my own opinion and others may disagree.
>>
>> Hope this helps,
>> Mark
>>
>> On Thu, 1 Dec 2016 at 22:05 Brian Tuffy  wrote:
>>
>> > Hi all,
>> > I'm fairly new to OSM, I map under the username OscarBrownbread.
>> > I have been mapping Castlebar and Co. Mayo. Recently I have been looking
>> > more at 

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[gmbo]

Am 11.12.2016 um 21:06 schrieb Frederik Ramm:

Hallo,

On 12/11/2016 06:55 PM, Rolf Eike Beer wrote:

[…]

Ab wann wäre das ein Import?

IMHO: definiv nein, das ist manuelles hinzufügen.

Nehmen wir einen extremen Fall: Ich habe über Jahre hinweg mit meinen
Kumpels diejenigen Restaurants ge-waypoint-et, in denen man meinem Pferd
kostenlos Wasser gegeben hat, und nun lade ich diese 1000 Waypoints zu
OSM hoch: Das wäre klar ein Import, denn wie bei anderen Importen auch
sollte die Community die Chance haben, sich vorher anzuschauen, ob ich
mir auch gut überlegt habe, wie ich vorgehe, um dabei nichts kaputtzumachen.
Ist in meinem konkreten Fall so, es handelt sich beim Sammeln um eine 
die Gruppe Motorradfahrer, dort sind auch von mir seit Jahren Parkplätze 
gesammelt worden um sie der Allgemeinheit zur Verfügung zu stellen.
Das ist bis 2013 über das Forum Ruhrpott-Viller  mit einer Liste 
Eintragung in Google Maps geschehen und ein zusatzliches Bereitstellen 
als GPX-Datei geschehen. Damals änderte Google die AGB und ich konnte 
die für mich nicht akzeptieren und suchte nach einer Alternative, die 
ich in OSM fand.
Ich versuche seidem auch die Gruppe Motorradfahrer auf z.B. der 
Dortmunder Motorradmesse von OSM zu überzeugen und finde dadurch immer 
mehr Mitarbeiter in OSM, die auch lernen mitzuarbeiten.
Motorradparkplätze wurden auch vorher schon in OSM getaggt. Ich habe 
dann angefangen da durch den Wikieintrag motorcycle_parking 
einheitlicheres Tagging zu erreichen. Die Seite ist inzwischen in viele 
Sprachen übersetzt.
Alle Parkplätze und veränderte die neu gemeldet wurden wurden seitdem in 
OSM eingeplegt.  Auf den Messen und anderen Veranstaltungen fand ich 
eine zweite Gruppe die solche Parkplätze gesammelt hat. Das ist der 
Bundesverband der Motorradfahrer die sich zu einem Verein zusammen 
geschlossen haben. Diese stellen eine eigene Liste zur Verfügung. Auch 
dort fand ich Freunde die schon mi OSM arbeiten.
In vielen Gesprächen haben alle daran beteiligten davon überzeugt dass 
eine Lösung alle Parkplätze in einer Liste zusammenzu führen und da wir 
die Koordinaten natürlich nach Möglichkeit in einer Karte sehen wollen, 
dies mit OSM anstelle von Google zu tun.
Da es auch mir widerstrebt so etwas einfach so per GPX in OSM zu laden 
und einfach einzuplegen, Da ja häufig der Parkplatz der Liste schon 
vorhanden ist, oder aber auch die Koordinaten nicht genau bekannt sind 
hätte dies zu Problemen führen können.
Also haben wir aus den 2 Listen eine zusammengesetzt und daraus eine 
gemacht. Dadurch wurde der größte Teil der Dopplungen entfernt.
Dann haben wir begonnen zu prüfen ob der Parkplatz schon in OSM 
eingetragen ist. Da dies aber alles für jeden Parkplatz einzeln 
gescheehen muß und ich und die anderen OSM-user feststellten, die viele 
Parkplätze fehlen noch in OSM und sind aber wenn man ein geübtes Auge 
hat auf Bing-Luftbildern zu erkennen oder zu erahnen auch eingetragen 
worden. Dafür habe ich an Regentagen auch schon viele Stunden 
eingeplegt. Dazu gehören viele Parkplätze, die ich selbst fotografiert 
habe oder Bilder zugesannt bekommen habe. Wenn ich mir nicht sicher war, 
habe ich ein fixme Pos ungeau angefügt um den Parkplatz dann  auf einer 
meiner Fahrten zu besuchen oder dem Melder den Punkt zeigen zu können 
und die Position zu korregieren. Natürlich reagiere ich bei den 
Eintragungen auf Meldungen zum Änderungssatz wo mich dann User zu den 
Punkten befragen.


Ich war wie geagt nach Gesprächen auf OSM- Stammtischen im Sommercamp 
2015 und der OpenRheinRuhr nicht davon ausgegangen, dass es sich dabei 
um Importe handelt. Die Liste sollte als Referenzliste für eine geplante 
Wochenaufgabe genutzt weden.



Um auch auf die inzwischen weiteren Antworten einzugehen, die die 
Revertierung betrift, die Michael, gemacht hat.
Ich kann dich inzwischen verstehen, mit dem was du gerade in deiner 
Antwort geschrieben hast, sogar noch viel besser.
Das Beispiel mit der Bahn habe ich deshalb genutzt weil mir gerade in 
meiner Umgebung beim Betrachten der Fixmes diese auffielen und ich mir 
gut vorstellen konnte warum die ungenau beim Mappen sind. Dort sieht man 
auch nur das Signal vorbeihuschen, kann sich das wichtigste dazu merken, 
selbst eine aufgezeichnete GPS-Spur enthielte große Ungenauigkeiten.


Aber um auf meine Problematik zurückzukommen, es ist nicht so einfach 
wenn der Melder nicht dem Standart OSM-Mitwirkenden entspricht.

Eine für mich optimale Meldung  wäre  z.B. eine der letzten für Oberhausen.

Bero Zentrum, Concordiastrasse 32
Am Eingang Nord
51.475228, 6.842295
3 – 6 Stellplätze
mit Bild vom Parkplatz.
Diese Meldung kommt von jemanden, dem ich letzten Monat OSM gezeigt und 
erklärt habe und im Januar am nächsten Treffen zu dem Thema teil nimmt. 
Hier sollte demnächst dann jemand selbst eintragen können.
Sie kann inzwischen die Koordinaten vom Handy absenden und hat sogar 
schon einen unbenutzten OSM Account. bittet mich dies in OSM 
einzutragen, was ich natürlich tue.

Re: [Talk-GB] GB Coastline - PGS vs OS

[David Groom]

Colin

I was more talking about the actual shape of the MHW rather than its 
position; if that makes sense.


some examples of problems in the Isle of Wight

1)  There's a section here  
http://www.openstreetmap.org/#map=17/50.66636/-1.48566, where the Bing 
imagery seems reasonably aligned to the gps tracks of the main road, but 
the gpx file for MHW seems to be too far to the north on the cliff area, 
and too far to the south on the area to the east.  this beach shelves 
relatively steeply so there is unlikely to be much difference between 
MHWS & MHWN


2) Even clearer is an area 
http://www.openstreetmap.org/#map=17/50.69439/-1.09414, OSM is much more 
accurate here than the OS Boundary Line


3)  The car park and ice rink here 
http://www.openstreetmap.org/#map=18/50.73237/-1.15736  were built 
sometime around 1990, but Boundary line  MHW would show these as flooded


4)  More inaccuracies here   
http://www.openstreetmap.org/#map=19/50.76650/-1.30029


David



-- Original Message --
From: "Colin Smale" 
To: talk-gb@openstreetmap.org
Sent: 11/12/2016 22:17:44
Subject: Re: [Talk-GB] GB Coastline - PGS vs OS


Hi David,

Looking at the spot you indicate on Bing imagery does indeed look like 
MHW should be above the salt-marsh areas. Looking at Google[1] it is 
however possible that the grass doesn't quite get submerged, even at 
the highest tides, so it might also be possible that it is strictly 
correct.


The Bing imagery is of course just a snapshot, and we don't know the 
state of the tide at the moment the photo was taken, so it can also be 
misleading. Even a personal visit is not really enough as MHW is 
apparently calculated over a 19-year cycle (not sure if OS use this 
though) and things could change a lot in that time. As MHW is an 
average, many tides will of course be higher.


The OS data looks a definite improvement for steeper coastlines, where 
combining OS admin boundaries with PGS coastlines produces many 
anomalies (admin boundary=MLW inland of coastline=MHW). I would 
definitely suggest applying the OS MHW data to address this kind of 
issue. But I agree, use of the OS data would need case-by-case 
judgements. However I still think the OS data is probably a better base 
to work from than (unimproved) PGS for reasons I mentioned earlier.


Could you give a couple of examples of problems you saw in the IoW?

//colin


[1] 
https://www.google.com/maps/@51.5386032,0.6292606,3a,24.7y,277.12h,84.08t/data=!3m6!1e1!3m4!1sMl8cwBlLLuOVtPES_DfkOQ!2e0!7i13312!8i6656


On 2016-12-11 22:30, David Groom wrote:

I suspect that even though much of the coastline is tagged 
"source=PGS" is has been amended by reference to Yahoo and after that 
Bing imagery, but the subsequent editors did not remove the 
"source=PGS" tag.


Certainly comparing your gpx file for the Isle of Wight with the 
coastline currently in OSM there appear a number of places where the 
gpx file does not accurately represent MHW.


I certainly would not want to see a wholesale replacement of what is 
in currently in OSM with OD Boundary Line data.


Looking here http://www.openstreetmap.org/#map=19/51.53546/0.60580 an 
area near Southend, unless the Bing imagery is outdated, the Boundary 
Line data seems to be an odd representation of the coastline.


David
On 11/12/2016 10:43, Colin Smale wrote:


Hi,

Most of the coastline is currently tagged as "source=PGS". As part of 
the Boundary-Line open data set OS provide MHW lines which look to be 
significantly better than the PGS data:


  * Much newer - updated twice a year, although I am not sure how old
the actual underlying survey data is (PGS coastlines seem to be
from 2006)
  * Better resolution - more nodes, smoother curves
  * Consistent with admin boundary data, so MLW never appears above
MHW (often a problem on rocky coastlines like Wales and Cornwall)

There are a couple of caveats when working with the OS data:

  * Where MHW=MLW, i.e. the MHW is colinear with the admin boundary 
at

MLW, there is a gap in the MHW data
  * The MHW data goes miles inland in tidal estuaries, which is
correct from the MHW standpoint, but for coastlines I think we
need to cut across the estuaries at the right point to form the
correct baseline
  * The MHW data is organised by area - down to constituency level.
Every time the line crosses the area boundary, it simply stops 
and

you need to load the adjacent area to continue the line

I have uploaded GPX versions of the October 2016 OS MHW data to 
http://csmale.dev.openstreetmap.org/os_boundaryline/mhw/ with a file 
per county / unitary area (I have not produced the files for the 
higher-level regions or the lower-level constituency areas).


In the Thames estuary around Southend and on the north Kent coast I 
have replaced the PGS data with the new OS data and to me it looks 
much better (in Potlatch) although the changes are not yet showing 
through on "the map". I think 

Re: [Talk-GB] GB Coastline - PGS vs OS

[Colin Smale]

This discusses the accuracy of the MHW/MLW data 

http://eprints.hrwallingford.co.uk/554/1/HRPP523_Error_analysis_of_Ordnance_Survey_map_tidelines.pdf


//colin 

On 2016-12-11 23:17, Colin Smale wrote:

> Hi David, 
> 
> Looking at the spot you indicate on Bing imagery does indeed look like MHW 
> should be above the salt-marsh areas. Looking at Google[1] it is however 
> possible that the grass doesn't quite get submerged, even at the highest 
> tides, so it might also be possible that it is strictly correct. 
> 
> The Bing imagery is of course just a snapshot, and we don't know the state of 
> the tide at the moment the photo was taken, so it can also be misleading. 
> Even a personal visit is not really enough as MHW is apparently calculated 
> over a 19-year cycle (not sure if OS use this though) and things could change 
> a lot in that time. As MHW is an average, many tides will of course be 
> higher. 
> 
> The OS data looks a definite improvement for steeper coastlines, where 
> combining OS admin boundaries with PGS coastlines produces many anomalies 
> (admin boundary=MLW inland of coastline=MHW). I would definitely suggest 
> applying the OS MHW data to address this kind of issue. But I agree, use of 
> the OS data would need case-by-case judgements. However I still think the OS 
> data is probably a better base to work from than (unimproved) PGS for reasons 
> I mentioned earlier. 
> 
> Could you give a couple of examples of problems you saw in the IoW? 
> 
> //colin
> 
> [1] 
> https://www.google.com/maps/@51.5386032,0.6292606,3a,24.7y,277.12h,84.08t/data=!3m6!1e1!3m4!1sMl8cwBlLLuOVtPES_DfkOQ!2e0!7i13312!8i6656
>  
> 
> On 2016-12-11 22:30, David Groom wrote: 
> I suspect that even though much of the coastline is tagged "source=PGS" is 
> has been amended by reference to Yahoo and after that Bing imagery, but the 
> subsequent editors did not remove the "source=PGS" tag.
> 
> Certainly comparing your gpx file for the Isle of Wight with the coastline 
> currently in OSM there appear a number of places where the gpx file does not 
> accurately represent MHW.
> 
> I certainly would not want to see a wholesale replacement of what is in 
> currently in OSM with OD Boundary Line data.
> 
> Looking here http://www.openstreetmap.org/#map=19/51.53546/0.60580 an area 
> near Southend, unless the Bing imagery is outdated, the Boundary Line data 
> seems to be an odd representation of the coastline.
> 
> David
> On 11/12/2016 10:43, Colin Smale wrote: 
> Hi,
> 
> Most of the coastline is currently tagged as "source=PGS". As part of the 
> Boundary-Line open data set OS provide MHW lines which look to be 
> significantly better than the PGS data:
> 
> * Much newer - updated twice a year, although I am not sure how old
> the actual underlying survey data is (PGS coastlines seem to be
> from 2006)
> * Better resolution - more nodes, smoother curves
> * Consistent with admin boundary data, so MLW never appears above
> MHW (often a problem on rocky coastlines like Wales and Cornwall)
> 
> There are a couple of caveats when working with the OS data:
> 
> * Where MHW=MLW, i.e. the MHW is colinear with the admin boundary at
> MLW, there is a gap in the MHW data
> * The MHW data goes miles inland in tidal estuaries, which is
> correct from the MHW standpoint, but for coastlines I think we
> need to cut across the estuaries at the right point to form the
> correct baseline
> * The MHW data is organised by area - down to constituency level.
> Every time the line crosses the area boundary, it simply stops and
> you need to load the adjacent area to continue the line
> 
> I have uploaded GPX versions of the October 2016 OS MHW data to 
> http://csmale.dev.openstreetmap.org/os_boundaryline/mhw/ with a file per 
> county / unitary area (I have not produced the files for the higher-level 
> regions or the lower-level constituency areas).
> 
> In the Thames estuary around Southend and on the north Kent coast I have 
> replaced the PGS data with the new OS data and to me it looks much better (in 
> Potlatch) although the changes are not yet showing through on "the map". I 
> think coastline changes are processed less frequently.
> 
> Any comments?
> 
> //colin
> 
> ___
> 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-es] Sobre importaciones y otros demonios

[yo paseopor]

Chapa ninguna, he aprendido cosas que nunca hubiera esperado, además muy
cercanas a mi, lo cual me ha hecho mucha ilusión.
A la luz de los datos aportados por el compañero, muy interesante por
cierto y reitero en público las disculpas que he dado en privado por si
alguna vez he menoscabado el trabajo realizado en Catastro, el tema
Barcelona cogería otros derroteros, ya que estamos llegando a la conclusión
de que Catastro nos aportará información muy útil, pero no los números de
portal.

Es por ello que habiéndolo hablado con los compañeros catalanes y con la
colaboración de Santiago Crespo nos vamos a poner a trabajar en la
importación de los números de portal de Barcelona ciudad, con los datos de
OpenData del Ajuntament de Barcelona. Gracias a un script de su diseño (de
kresp0) se conjugarán dos archivos en los que quedarán las principales
propiedades: número de portal, calle a la que pertenece y código postal.
Hemos comprobado los datos , son fiables, y hablaremos con el ayuntamiento
para obtener un permiso explícito y claro sobre el uso de esos datos.
Podeis consultar la wiki en
https://wiki.openstreetmap.org/wiki/BCN_Housenumbers_Import (si falla
alguna cosa, si no está del todo clarificado es que se ha hecho a imagen y
semejanza de las importaciones de Madrid y puede tener cosas a modificar
aún) .
Es una importación grande (más de 17 nodos) así que aunque se haga
colaborativa va a requerir trabajo, por lo que contamos con toda la
comunidad para ello.

Muchas gracias a todos y todas los que habeis colaborado (desde que
iniciamos este debate) ,colaborais y colaborareis en este y en futuros
procesos de este tipo destinados a mejorar notablemente la calidad y la
usabilidad de OSM en España.

Salut i importaciones
yopaseopor

PD: Cartociudad del IGN me parece una opción interesante para explorar como
fuente de pueblos pequeños que no tenemos el gusto de conocer y de la cual
también podríamos estudiar importación de datos, ¿no creeis?
http://www.cartociudad.es/visor/

PD2: Larga vida a Catastro y a quienes lo llevaron adelante, lo mantienen y
lo mantendrán.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Fumetteria

[Alessandro Pozzato]

Il 08/12/2016 13:00, talk-it-requ...@openstreetmap.org ha scritto:

Date: Wed, 7 Dec 2016 18:02:56 +0100
From: "Alberto Nogaro" 

Forse puoò andare questo:

https://wiki.openstreetmap.org/wiki/Tag:shop%3Danime

Ciao,
Alberto


Ringrazio Alberto per l'utile suggerimento, tuttavia ho preferito usare 
la combinazione shop=books + books=comic, suggerita dal wiki 
http://wiki.openstreetmap.org/wiki/Key:books che nel frattempo ho 
trovato. Questo perché l'attività principale dello shop=anime non è la 
vendita di fumetti ma di video, mentre shop=books significa la vendita 
di materiale cartaceo rilegato.


Alessandro Pozzato

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

Re: [Talk-GB] GB Coastline - PGS vs OS

[Colin Smale]

Hi David, 

Looking at the spot you indicate on Bing imagery does indeed look like
MHW should be above the salt-marsh areas. Looking at Google[1] it is
however possible that the grass doesn't quite get submerged, even at the
highest tides, so it might also be possible that it is strictly correct.


The Bing imagery is of course just a snapshot, and we don't know the
state of the tide at the moment the photo was taken, so it can also be
misleading. Even a personal visit is not really enough as MHW is
apparently calculated over a 19-year cycle (not sure if OS use this
though) and things could change a lot in that time. As MHW is an
average, many tides will of course be higher. 

The OS data looks a definite improvement for steeper coastlines, where
combining OS admin boundaries with PGS coastlines produces many
anomalies (admin boundary=MLW inland of coastline=MHW). I would
definitely suggest applying the OS MHW data to address this kind of
issue. But I agree, use of the OS data would need case-by-case
judgements. However I still think the OS data is probably a better base
to work from than (unimproved) PGS for reasons I mentioned earlier. 

Could you give a couple of examples of problems you saw in the IoW? 

//colin

[1]
https://www.google.com/maps/@51.5386032,0.6292606,3a,24.7y,277.12h,84.08t/data=!3m6!1e1!3m4!1sMl8cwBlLLuOVtPES_DfkOQ!2e0!7i13312!8i6656


On 2016-12-11 22:30, David Groom wrote:

> I suspect that even though much of the coastline is tagged "source=PGS" is 
> has been amended by reference to Yahoo and after that Bing imagery, but the 
> subsequent editors did not remove the "source=PGS" tag.
> 
> Certainly comparing your gpx file for the Isle of Wight with the coastline 
> currently in OSM there appear a number of places where the gpx file does not 
> accurately represent MHW.
> 
> I certainly would not want to see a wholesale replacement of what is in 
> currently in OSM with OD Boundary Line data.
> 
> Looking here http://www.openstreetmap.org/#map=19/51.53546/0.60580 an area 
> near Southend, unless the Bing imagery is outdated, the Boundary Line data 
> seems to be an odd representation of the coastline.
> 
> David
> On 11/12/2016 10:43, Colin Smale wrote: 
> 
>> Hi,
>> 
>> Most of the coastline is currently tagged as "source=PGS". As part of the 
>> Boundary-Line open data set OS provide MHW lines which look to be 
>> significantly better than the PGS data:
>> 
>> * Much newer - updated twice a year, although I am not sure how old
>> the actual underlying survey data is (PGS coastlines seem to be
>> from 2006)
>> * Better resolution - more nodes, smoother curves
>> * Consistent with admin boundary data, so MLW never appears above
>> MHW (often a problem on rocky coastlines like Wales and Cornwall)
>> 
>> There are a couple of caveats when working with the OS data:
>> 
>> * Where MHW=MLW, i.e. the MHW is colinear with the admin boundary at
>> MLW, there is a gap in the MHW data
>> * The MHW data goes miles inland in tidal estuaries, which is
>> correct from the MHW standpoint, but for coastlines I think we
>> need to cut across the estuaries at the right point to form the
>> correct baseline
>> * The MHW data is organised by area - down to constituency level.
>> Every time the line crosses the area boundary, it simply stops and
>> you need to load the adjacent area to continue the line
>> 
>> I have uploaded GPX versions of the October 2016 OS MHW data to 
>> http://csmale.dev.openstreetmap.org/os_boundaryline/mhw/ with a file per 
>> county / unitary area (I have not produced the files for the higher-level 
>> regions or the lower-level constituency areas).
>> 
>> In the Thames estuary around Southend and on the north Kent coast I have 
>> replaced the PGS data with the new OS data and to me it looks much better 
>> (in Potlatch) although the changes are not yet showing through on "the map". 
>> I think coastline changes are processed less frequently.
>> 
>> Any comments?
>> 
>> //colin
> 
> ___
> 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: [OSM-talk-ie] Can Townlands be split for Civil parishes and barony boundries?

[Patrick Matthews]

> My own opinion would be that townlands shouldn't be split in OSM and if
> they overlap parishes, then it's up to the software using the OSM data to
> figure out how to handle them.
>
> As far as I understand it, townlands don't necessarily add up to civil
> parishes, civil parishes don't necessarily add up to baronies and baronies
> don't necessarily add up to counties.


Civil parishes and baronies are independent of each other - one is not a
subdivision of the other.


> Furthermore, townlands don't
> necessarily add up to electoral divisions.  In rural areas, the GSGS3906
> map splits the townland into 2 pieces (e.g. Agall (ED Derrycoooly) and
> Agall (ED Screggan) at
> http://maps.openstreetmap.ie/?zoom=16=53.26048=-7.
> 59323=B00T,
> but in urban areas, it doesn't, it just cuts the ED (and town) boundary
> through the townland e.g.
> http://maps.openstreetmap.ie/?zoom=15=52.80303=-6.
> 73163=B00T.
> Make of that what you will!
>

In the Agall example, the townland is "divided" between two civil parishes
and these two "parts" also
happen to be in different electoral divisions. After 1898, the civil parish
boundary was not shown when
two adjacent "parts" were in the same electoral division.

In the second example, you have a single townland which is spilit between
an urban and rural electoral
division (again, before 1898 both the urban and rural portions would have
formed a single poor law
electoral division. (As an aside, the mid-20th century editions of the 6
and 25-inch maps by OSNI
in Northern Ireland didn't show townland boundaries at all within urban
districts.)

The original practice of the Ordnance Survey, FWIW, was to treat any
townland "divided" between two
civil parishes or two baronies as being two separate townlands. The
population returns for the 1901 and
1911 censuses - after the 1898 Local Government Act - continue to list the
two "parts" of a townland
separately even where both lie within the same single electoral division.


> Regarding some of your specific issues:
> 3: I've come across several areas with CPs covering 2 non adjoining areas
> so this doesn't look that unusual e.g.:
> http://www.openstreetmap.org/relation/4280429
> 4: I think it's just awkwardly shaped.  Not sure if there's a boundary at
> the narrow part or not on
> http://maps.openstreetmap.ie/?zoom=16=53.8103=-9.
> 2563=B00T,
> but I don't see the name for the second townland on the GSGS3906 map if it
> is.
>
> Bear in mind that this is all just my own opinion and others may disagree.
>
> Hope this helps,
> Mark
>
> On Thu, 1 Dec 2016 at 22:05 Brian Tuffy  wrote:
>
> > Hi all,
> > I'm fairly new to OSM, I map under the username OscarBrownbread.
> > I have been mapping Castlebar and Co. Mayo. Recently I have been looking
> > more at townlands
> >
> > I have found many spelling errors in townland names (approx 10) in my
> > locality. Cross referencing them with the loganim data helped correct
> them.
> > Anyway, I now see many other challenges, I see many townlands that look
> > like they should be split. This is usually because of civil parishes
> (CPs)
> > or baronies going through them.
> >
> > Here are some of the issues I have come across in my area.
> > (0) townland spelling mistakes due to hard-to-read or missing letters in
> > the Brittish War Maps source
> > (1) Civil parish "Balla" missing
> > (2) CP "Mayo" is split into two parts, "Mayo (clanmorris portion)" and
> > "Mayo (kilmaine portion)" due to different baronies
> > (3) townland "Brownhall Demense" belonging to CP "Mayo" disconnected from
> > the rest of the CP (disconnected by the CP Balla which we still need to
> add
> > to OSM). This forms two closed ways in the boundary relation instead of
> > one.
> > (4) townland "Lugaphuill" really looks like it should be split in two
> > separate townlands with the same name that border eachother, but it is
> > currently one big townland in OSM. Now the name label (centroid) is in
> > another townland.
> > http://www.openstreetmap.org/#map=16/53.8103/-9.2563=N
> >
> > Ok, So I am Not looking for advice on how to solve each issue, that I can
> > try myself as I go forward. If you are curious, you can check out my OSM
> > map notes here.
> > http://www.openstreetmap.org/note/799945#map=13/53.7623/-9.1082=N
> .
> > But, I do need to know how to split townlands,
> >
> > My question is, Should we split townlands to make parish/barony borders
> > more accurate?
> > This results in townlands with the exact same name bordering eachother.
> > Wouldn't this result in confusion for search engines, programming
> database
> > etc. ?? Is it even possible to handle this?
> > If we do split them (as it is shown on the more recent maps), should we
> > name them differently? e.g. ballytown #1, ballytown #2 ?
> > Possibly, name= ballytown, name_official=ballytown#1 or something like
> > that?
> > I suppose we should rename but Townland names from the maps already
> 

Re: [OSM-talk] Use policies update

[Simon Poole]

Am 09.11.2016 um 12:42 schrieb Martin Koppenhoefer:
>
> 2016-11-06 0:25 GMT+01:00 Simon Poole  >:
...
>
> I'm not sure it is like this. Just because the code to produce the
> work has a CC0 license attached to it does not necessarily mean that
> the resulting cartography is also free of rights. At least the
> copyright page at http://www.openstreetmap.org/copyright clearly has a
> different claim on it (if deliberately or as result of oversight is
> not clear to me).
>  
>
> Or are we claiming that we are actually licensing the design/look
> and feel of the standard tiles on CC by-SA terms (and by that have
> rights in any derivatives of that style) and you can't actually
> use openstreetmap-carto style sheet to produce a style that is
> visually similar to our standard style?
>
> that's what we seem to do right now, yes.
>
> Admittedly there is quite some probability that the current claim of
> cc-by-sa 2.0 cartography is not because the creators of this work had
> been requiring it (AFAIK originally Steve Chilton and his team, now
> Andy and all the other contributors to the style), as they have
> expressed consent / will to release the style in CC0.

https://github.com/gravitystorm/openstreetmap-carto/pull/2474 is likely
relevant to this point.

>
> What we actually might want to achieve with the cc-by-sa on the tiles
> is that people who use tiles produced and distributed with our
> ressources will have to credit OSM for this and should not be able to
> restrict the further downstream distribution.
>

True, except, naturally, that that is silly (standard style tiles
created on OSMF infrastructure are indistinguishable from such rendered
somewhere else)  and creates more issues than it solves. And it is still
not clear what we are licensing in this case, assuming that both the
style and the cartography generated by it are CC0 (note: yes we have to
use a licence that guarantees downstream attribution of the data source).

Simon 

> Cheers,
> Martin



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

Re: [Talk-GB] GB Coastline - PGS vs OS

[David Groom]

I suspect that even though much of the coastline is tagged "source=PGS" 
is has been amended by reference to Yahoo and after that Bing imagery, 
but the subsequent editors did not remove the "source=PGS" tag.


Certainly comparing your gpx file for the Isle of Wight with the 
coastline currently in OSM there appear a number of places where the gpx 
file does not accurately represent MHW.


I certainly would not want to see a wholesale replacement of what is in 
currently in OSM with OD Boundary Line data.


Looking here http://www.openstreetmap.org/#map=19/51.53546/0.60580 an 
area near Southend, unless the Bing imagery is outdated, the Boundary 
Line data seems to be an odd representation of the coastline.


David
On 11/12/2016 10:43, Colin Smale wrote:


Hi,

Most of the coastline is currently tagged as "source=PGS". As part of 
the Boundary-Line open data set OS provide MHW lines which look to be 
significantly better than the PGS data:


  * Much newer - updated twice a year, although I am not sure how old
the actual underlying survey data is (PGS coastlines seem to be
from 2006)
  * Better resolution - more nodes, smoother curves
  * Consistent with admin boundary data, so MLW never appears above
MHW (often a problem on rocky coastlines like Wales and Cornwall)

There are a couple of caveats when working with the OS data:

  * Where MHW=MLW, i.e. the MHW is colinear with the admin boundary at
MLW, there is a gap in the MHW data
  * The MHW data goes miles inland in tidal estuaries, which is
correct from the MHW standpoint, but for coastlines I think we
need to cut across the estuaries at the right point to form the
correct baseline
  * The MHW data is organised by area - down to constituency level.
Every time the line crosses the area boundary, it simply stops and
you need to load the adjacent area to continue the line

I have uploaded GPX versions of the October 2016 OS MHW data to 
http://csmale.dev.openstreetmap.org/os_boundaryline/mhw/ with a file 
per county / unitary area (I have not produced the files for the 
higher-level regions or the lower-level constituency areas).


In the Thames estuary around Southend and on the north Kent coast I 
have replaced the PGS data with the new OS data and to me it looks 
much better (in Potlatch) although the changes are not yet showing 
through on "the map". I think coastline changes are processed less 
frequently.


Any comments?

//colin





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

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hallo gmbo, hallo Rest,

Am 11.12.2016 um 17:34 schrieb gmbo:
> Ich hoffe, die Mailingliste ist der für mich richtige Startpunkt
> einer Diskussion über die Frage, Wann ist das Editieren in OSM ein
> Import?

Ja, die Mailingliste ist richtig.

> Ich war bisher davon ausgegangen und auch Gespräche auf
> OSM-Stammtischen gingen in diese Richtung, das ich mit einer selbst
> gesammelten Liste von mich interessierenden Punkten, die schon
> länger in OSM gepflegt werden die ich dann einzeln, durch
> freigegebene Luftbilder überprüfe, und dann eintrage keinen Import
> im Sinne von 
> https://wiki.openstreetmap.org/wiki/DE:Import/Guidelines handelt.

Für alle, die nicht tagtäglich schauen, worüber in den vielen
Änderungssatzdiskussionen diskutiert wird [1], möchte ich kurz die
Vorgeschichte dieser Mail aus meiner Perspektive darstellen.

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

Ich hatte mir dann, weil das Import-artig aussah, mit der Overpass-API
nach kürzlich geänderten/eingetragenen Motorradparkplätzen im Norden
Baden-Württembergs gesucht und einen auf dem Marktplatz in Bönnigheim
gefunden. Ich kenne den Marktplatz flüchtig, ich komme aus der Gegend.
Auf Basis recht frischer Mapillary-Bilder (September 2016) kam ich zum
Entschluss, dass an der Nordostecke des Marktplatzes kein
Motorradparkplatz sein kann. Dort ist Außengastronomie. Wenn dann läge
der Motorradparkplatz auf der diagonal gegenüberliegenden Seite. Die
Bilder sind dort leider nicht hochauflösend genug, um das blau-weiße
Schild eindeutig zu identifiziere – es könnte auch ein Parkplatz für
Schwerbehinderte sein.

Für einen "Import" fand ich die Qualität nicht gut genug. Wer
importiert, sollte auf keinen Fall Objekte hochladen, die mit einem
Fixme versehen werden müssen. Die Erfahrung zeigt, dass sich keine um
solche Fixmes kümmert. Wenn ein Fixme "Position prüfen" an einem
Motorradparkplatz getaggt ist, dann war die Person wohl nicht vor
Ort?! Das übrige Tagging war nicht hervorragend. Du hast an vielen
Motorradparkplätzen name=* getaggt, dessen Existenz ich sehr bezweifle.

Ich hatte den Import *vorsichtig* mit meinem Benutzerkonto
Nakaner-repair revertiert. Das heißt, ich habe nur die Änderungssätze
revertiert, die in einem ihrer Änderungssatz-Tags "BDVM" oder "BVDM"
enthielten. Das waren 64 Änderungssätze. Der Revert erfolgte durch
folgenden Änderungssatz:
https://www.openstreetmap.org/changeset/44147307

Ich habe absichtlich vorsichtig revertiert. Ich hätte auch großzügig
alles mit "Motorradparkplatz" revertieren können. Das fand ich selbst
viel zu weitreichend, schließĺich hatte ich mindestens einen
Änderungssatz entdeckt, dessen Quellenangabe auf Ortskenntnis hindeutete
.

Hätte ich nicht beim allerersten Motorradparkplatz, den ich angeschaut
habe (Auswahlkriterium war die Ortkenntnis/räumliche Nähe zu meinem
Heimatort), Fehler gefunden, hätte ich mir selbst schwerer getan, die
Frage "Soll ich revertieren?" mit Ja zu beantworten.

> Wenn ich also zum Beispiel viel mit der Bahn fahre und die Signale 
> aufnehmen möchte, schreibe ich immer wenn ich ein Signal sehe den
> Typ und die grobe Position in einem Notizbuch auf. Diese tage ich
> wenn mir wieder ein Rechner zur Verfügung steht in OSM ein. Da ich
> einigermaßen gewissenhaft arbeite, schaue ich ob ich die Position 
> durch freigegebene Luftbildaufnahmen näher bestiimmen kann, um die 
> Signalstandorte exakt zu setzten. Ich spreche mit freunden darüber
> und diese melden mir weitere Signalstandorte, die ich ebenso mit
> eintrage, da sie es selbst so nicht kennen aber von der ihnen
> beschriebenen Idee freier Daten in OSM überzeugt sind. Der nächste
> Schritt für mich ist ein Heranführen der Freunde an OSM, damit sie
> die Signale selbst einplegen können.
> 
> Ab wann wäre das ein Import?

Wenn ich alle Signale vor Ort gesehen habe oder durch Fotos einen den
örtlichen Besuch ersetzenden Kenntnisstand erreicht habe, ist es kein
Import. Wenn ich Kumpels systematisch ein Bahnnetz abfahre, Signal für
Signal eintrage, wir alles vor Ort gesehen haben und Luftbilder als
eine zusätzliche Quelle nutzen, ist es organisiertes Mapping. Es
empfiehlt sich, solches vorher anzukündigen.

> Wenn ich also ein Paar Freunde habe die eine solche Sammlung von 
> Signalstandorten auf die gleiche Weise gesammelt haben und mir
> ihre bisher gesammelten Punkte übergeben, die ich dann auch mit
> eintrage. Ist das also jetzt ein Import?

Wenn man vor Ort gewesen ist, kann man bei Widersprüchen zwischen den
Aufzeichnungen und den Luftbildern bzw. zwischen den Aufzeichnungen
und den schon vorhandenen OSM-Daten besser unterscheiden.

> Ab wann muß ich mir für das Einplegen von solchen Punkten Gedanken 
> darüber machen ein eigenen Import Account anzulegen, und den auf
> der nur enlischsprachigen Liste zu diskutieren, auch wenn ich die
> Hälfte der Antwoten nur halb verstehe, da ich nur über einen weng
> benutzten Grundwortschatz verfüge und Übersetzer wie Bing und
> 

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[Martin Koppenhoefer]

sent from a phone

> On 11 Dec 2016, at 17:34, gmbo  wrote:
> 
> Ab wann wäre das ein Import?


ich denke, die Grenze ist da, wo Du Daten eingibst, die Du nicht selbst erhoben 
hast, und wo Du die Stelle nicht selbst kennst. Ob das "manuell"/mechanisch 
oder automatisch geschieht ist im Prinzip egal. Die Freunde die Dich bitten, 
deren (selbst kürzlich erhobenen) Daten einzugeben, sind ein Grenzfall, wo es 
zwar nach meiner Definition ein Import wäre, wo ich es aber nicht so streng 
sehen würde (d.h. sofern die Daten mit dem Auftrag sie zu osm hochzuladen 
übergeben werden, sollte es lizenztechnisch kein Problem geben, auch nicht bei 
einem Wechsel der Lizenz seitens osm, und wenn Du die Leute kennst wirst Du 
ggf. abschätzen können, wie sorgfältig die vorgehen, bzw wie akkurat deren 
Daten vermutlich sein werden)


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

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Martin Koppenhoefer]

sent from a phone

> On 11 Dec 2016, at 13:59, Garry  wrote:
> 
> Hat die Straße noch eine andere Funktion außer "Autobahnauffahrt"?
> D.h. dient sie auch als Zufahrt zu Forstwegen, Autobahnmeisterei o.ä.?
> Wenn ausschließlich Autobahnzufahrt würde ich sie auf jeden Fall als 
> motorway-link taggen um ganz klar darzustellen:


+1, ab dem Autobahn-anfangsschild bzw. bis zum Autobahnendeschild. Zufahrt zu 
Forstwegen etc. kann man anhand der Beschreibung eigentlich ausschließen, da 
die nach dem Autobahnschild sowieso nicht mehr fahren dürfen.

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

Re: [OSM-talk] Maps.me editing

[Rob Nickerson]

On 10 December 2016 at 21:01, Martin Koppenhoefer 
wrote:

>
> it seems sufficiently scalable for deleting stuff like settlements.
> Deletions are hard to spot, 
>

Maybe, but if deletions are hard to spot then shouldn't we be making the
change tracker tools better rather than restricting this type of edit?

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

Re: [Talk-GB] [OSM-talk] Maps.me editing

[Rob Nickerson]

On 10 December 2016 at 21:01, Martin Koppenhoefer 
wrote:

>
> it seems sufficiently scalable for deleting stuff like settlements.
> Deletions are hard to spot, 
>

Maybe, but if deletions are hard to spot then shouldn't we be making the
change tracker tools better rather than restricting this type of edit?

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

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[Frederik Ramm]

Hallo,

On 12/11/2016 06:55 PM, Rolf Eike Beer wrote:
> […]
>> Ab wann wäre das ein Import?
> 
> IMHO: definiv nein, das ist manuelles hinzufügen.

Nehmen wir einen extremen Fall: Ich habe über Jahre hinweg mit meinen
Kumpels diejenigen Restaurants ge-waypoint-et, in denen man meinem Pferd
kostenlos Wasser gegeben hat, und nun lade ich diese 1000 Waypoints zu
OSM hoch: Das wäre klar ein Import, denn wie bei anderen Importen auch
sollte die Community die Chance haben, sich vorher anzuschauen, ob ich
mir auch gut überlegt habe, wie ich vorgehe, um dabei nichts kaputtzumachen.

Wenn ich hingegen die Liste nur als "Mappinghilfe" benutze, von Hand
alle Objekte in OSM abklappere und Tags ergänze oder auch mal ein
Restaurant dazufüge, dann ist es doch eher Handarbeit.

Leider ist zwischen beidem eine relativ große Grauzone, es gibt ja
inzwischen bezahlte Mapper, die ihre "Handarbeit" so schnell verrichten,
dass man sich fragt, ob da überhaupt noch Zeit für die gebotene Sorgfalt
bleibt ;)

Bye
Frederik

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



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

Re: [Talk-it] Riutilizzo informazioni PRG, PAT, PI in Openstreetmap

[Maurizio Napolitano]

> è scritto chiaramente: "testi", elaborati grafici non sono testi. Forse c'è
> un'altra parte dove dice che gli allegati sono compresi?

Considera che la legge e' del ' 41 tant'e' che all'articolo 11 si trova scritto

"Alle Amministrazioni dello Stato, al *Partito Nazionale Fascista*,
alle Provincie ed ai Comuni spetta il diritto di autore sulle opere
create e pubblicate sotto il loro nome ed a loro conto e spese. "
(con relativo richiamo all'articolo 29)

Capisco comunque il tuo punto, ho visto molto spesso PRG composti da
testo accompagnati da una parte grafica necessaria
all'interpretazione.

Chiedo a giuristi per sicurezza.

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

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Robert]

Am 11. Dezember 2016 um 13:16 schrieb Rolf Eike Beer :
> Am Sonntag 11 Dezember 2016, 12:24:02 schrieb Robert:
>> Zu Beginn der Straße, also an der letzten
>> Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
>> erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
>> Landesstraße.
>>
>> Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
>> dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
>> auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
>> vorgefunden werden kann.
>
> Eine völlig unrepresentative Stichprobe, die ich gerade entlang der A2 und A7
> gemacht habe, zeigt, dass das "nur der baulich je Fahrtrichtung getrennte
> Teil", über den du im Wiki vermutlich auch gestolpert bist, allgemein
> ignoriert wird. Ansonsten hätte ich nämlich auch gesagt, dass das definitiv
> trunk_link ist.

Du meinst bestimmt motorway_link? Denn eine Schnellstraße (trunk) ist
eigentlich dort nicht vorhanden, soweit man nicht die Anbindungsrampe,
die hier etwas länger ausfällt, als trunk statt motorway_link sieht.
Wenn zunächst das Zeichen "Beginn Kraftfahrstraße" und dann "Beginn
Autobahn" kommen würde, würde ich das auch so sehen. Aber die BAB
beginnt beschilderungstechnisch direkt an der Kreuzung - und damit
auch die ganzen Fahrzeugeinschränkungen. Die Straße vor der Kreuzung
ist eine normale secondary und dann wird's zur Autobahn.


Robert

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

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Robert]

Am 11. Dezember 2016 um 13:59 schrieb Garry :
> Hat die Straße noch eine andere Funktion außer "Autobahnauffahrt"?
> D.h. dient sie auch als Zufahrt zu Forstwegen, Autobahnmeisterei o.ä.?

Nein.

> Wenn ausschließlich Autobahnzufahrt würde ich sie auf jeden Fall als
> motorway-link taggen um ganz klar darzustellen:
> Hier geht es ausschließlich auf die Autobahn und Du hast hier nichts
> verloren wenn Dein Fahrzeug nicht für die Autobahn erlaubt ist.
> Es geht ja vorrangig um die verkehrliche Bedeutung/Widmung und nicht darum,
> wer für den
> Unterhalt zuständig ist. Und das wird ja in Deinem Fall eindeutig mit dem
> Zeichen 330.1 angezeigt.

Das sehe ich auch so. So war es auch die letzten sieben Jahre getaggt.

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

Re: [Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[Rolf Eike Beer]

[…]
> Ab wann wäre das ein Import?

IMHO: definiv nein, das ist manuelles hinzufügen.

Bitte für solche Diskussionen nicht auf eine vorherige antworten, sondern eine 
neue Mail an die Liste schicken, ansonsten kommt das Threading im geeigneten 
Mailprogrammen unnötig durcheinander.

Gruß

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Mozambique's living streets

[john whelan]

In Lichinga, Niassa, Mozambique

http://www.openstreetmap.org/node/335126704#map=15/-13.3219/35.2649

practically every street is labeled highway=living_street including many
that look quite wide to me.  In other parts of the city the same type of
street when viewed in Bing is labeled residential.

I'm not talking narrow alleyways here.

Cheerio John

On 11 December 2016 at 11:29, Martin Koppenhoefer 
wrote:

>
> 2016-12-11 11:55 GMT+01:00 Tobias Zwick :
>
>> These kinds of streets are not only common in old town centers in Europe
>> but can be found in any place in the world that hadn't been built with
>> cars in mind, in shanty towns and also in modern (non-shanty) towns -
>> especially in Asia.
>>
>
>
> +1
>
>
>
>>
>> Now, the alley tag mentioned is problematic because there is no clear
>> definition what may still count as an alley and what should be a
>> residential road already.
>>
>
>
>
> For me it's basically an alley if it's too narrow to be a residential
> street. I'd expect the osm residential streets to be passable with a
> "normal" car plus a pedestrian, otherwise it would be an alley  or a path,
> or (if motor vehicles are not permitted), likely a footway or bikepath.
> Also if the turns are too sharp (corners) for a car it would not be a
> residential street. Typically the residential street will have width for 2
> cars to pass, plus pedestrians on each side.
>
> Cheers,
> Martin
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cz] zákon o KČT

[Matěj Cepl]

On 2016-12-08, 15:55 GMT, Ha Noj wrote:
> Ahoj,
>
> tohle nás asi bude zajímat, nový zákon: KČT se zasloužil o stát.
>
> http://www.ceskatelevize.cz/ct24/domaci/1976920-ceske-turisticke-trasy-jsou-svetovy-unikat-chranit-je-mohl-samostatny-zakon
>
> http://www.psp.cz/sqw/text/orig2.sqw?idd=120094

A velice kritický (a správný) komentář Zbyňka Petráčka 
v Lidovkách 
http://www.lidovky.cz/petracek-vy-jste-znackar-lidovci-navrhuji-chranit-turisticke-cesty-zakonem-17y-/nazory.aspx?c=A161209_092623_ln_nazory_ele

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
According to the Franciscan priest Richard Rohr, spirituality is
not for people who are trying to avoid hell; it is for people
who have been through hell. In many ways, spirituality is about
what we do with our pain. And the truth is, if we don't
transform it, we will transmit it.
-- Al Gustafson


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

[Talk-de] Wann ist das Eintragen von POIs ein IMPORT.

[gmbo]

Ich hoffe, die Mailingliste ist der für mich richtige Startpunkt einer 
Diskussion über die Frage, Wann ist das Editieren in OSM ein Import?


Ich war bisher davon ausgegangen und auch Gespräche auf OSM-Stammtischen 
gingen in diese Richtung, das ich mit einer selbst gesammelten Liste von 
mich interessierenden Punkten, die schon länger in OSM gepflegt werden 
die ich dann einzeln, durch freigegebene Luftbilder überprüfe, und dann 
eintrage keinen Import im Sinne von 
https://wiki.openstreetmap.org/wiki/DE:Import/Guidelines handelt.


Wenn ich also zum Beispiel viel mit der Bahn fahre und die Signale 
aufnehmen möchte, schreibe ich immer wenn ich ein Signal sehe den Typ 
und die grobe Position in einem Notizbuch auf. Diese tage ich wenn mir 
wieder ein Rechner zur Verfügung steht in OSM ein.
Da ich einigermaßen gewissenhaft arbeite, schaue ich ob ich die Position 
durch freigegebene Luftbildaufnahmen näher bestiimmen kann, um die 
Signalstandorte exakt zu setzten. Ich spreche mit freunden darüber und 
diese melden mir weitere Signalstandorte, die ich ebenso mit  eintrage, 
da sie es selbst so nicht kennen aber von der ihnen beschriebenen Idee 
freier Daten in OSM überzeugt sind. Der nächste Schritt für mich ist ein 
Heranführen der Freunde an OSM, damit sie die Signale selbst einplegen 
können.


Ab wann wäre das ein Import?

Wenn ich also ein Paar Freunde habe die eine solche Sammlung von 
Signalstandorten auf die gleiche Weise gesammelt haben und mir ihre 
bisher gesammelten Punkte übergeben, die ich dann auch mit eintrage.

Ist das also jetzt ein Import?


Ab wann muß ich mir für das Einplegen von solchen Punkten Gedanken 
darüber machen ein eigenen Import Account anzulegen, und den auf der nur 
enlischsprachigen Liste zu diskutieren, auch wenn ich die Hälfte der 
Antwoten nur halb verstehe, da ich nur über einen weng benutzten 
Grundwortschatz verfüge und Übersetzer wie Bing und Google nur 
unverständliche Übersetzungen machen.


Gut meine Beschreibung ist nur ein realistisches Beispiel, welches ich 
gewählt habe um einen einfachen Einstieg zu haben.


Gruß
Gisbert



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

Re: [OSM-talk] Mozambique's living streets

[Martin Koppenhoefer]

2016-12-11 11:55 GMT+01:00 Tobias Zwick :

> These kinds of streets are not only common in old town centers in Europe
> but can be found in any place in the world that hadn't been built with
> cars in mind, in shanty towns and also in modern (non-shanty) towns -
> especially in Asia.
>


+1



>
> Now, the alley tag mentioned is problematic because there is no clear
> definition what may still count as an alley and what should be a
> residential road already.
>



For me it's basically an alley if it's too narrow to be a residential
street. I'd expect the osm residential streets to be passable with a
"normal" car plus a pedestrian, otherwise it would be an alley  or a path,
or (if motor vehicles are not permitted), likely a footway or bikepath.
Also if the turns are too sharp (corners) for a car it would not be a
residential street. Typically the residential street will have width for 2
cars to pass, plus pedestrians on each side.

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

Re: [Talk-it] Riutilizzo informazioni PRG, PAT, PI in Openstreetmap

[Martin Koppenhoefer]

2016-12-11 15:01 GMT+01:00 Maurizio Napolitano :

> "Le disposizioni di questa legge non si applicano ai testi degli atti
> ufficiali dello stato e delle Amministrazioni pubbliche, sia italiane
> che straniere. "
>



è scritto chiaramente: "testi", elaborati grafici non sono testi. Forse c'è
un'altra parte dove dice che gli allegati sono compresi?

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

Re: [Talk-cz] dotaz na vyčištění cache v JOSM

[Zdeněk Pražák]

díky za odkaz


-- Původní zpráva --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 10. 12. 2016 12:01:55
Předmět: Re: [Talk-cz] dotaz na vyčištění cache v JOSM

"
Cesta je popsaná tady https://josm.openstreetmap.de/wiki/Help/Preferences#
Windows(https://josm.openstreetmap.de/wiki/Help/Preferences#Windows) (kazdy 
OS to ma trochu jinak, Win jsou jen prvni v seznamu)



A pod tim je adresar "cache" - z mych zkusenosti lze jeho obsah beztrestne 
smazat :)




HPM




Dne 10. 12. 2016 11:30 napsal uživatel "Michal Pustějovský" mailto:michal.pustejov...@seznam.cz)>:
"
Ony se ty dlaždice budou uchovávat někde na disku, takže je půjde smazat i 
odtamtaď. Na Windowsech to bude buď temp nebo %appdata%.


10. prosince 2016 8:28:45 CET, majka  napsal:" 
Krátce - ano, v nastavení je možné vymazat. Ale - jde to jen vše pro každý 
jednotlivý podklad, tedy například kompletní Bing, ne jen staré dlaždice.



Dne 10. 12. 2016 7:20 napsal uživatel "Zdeněk Pražák" :
"
chtěl jsem se zeptat, zda v JOSM existuje možnost vyčistit cache od starých 
stažených podkladových dlaždic


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

"





Talk-cz mailing listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz
"

-- 
Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím 
moji stručnost.

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

"

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

Re: [OSM-talk-ie] Can Townlands be split for Civil parishes and barony boundries?

[Brian Tuffy]

Hi Mark,
Thanks for your feedback, I have made most of the changes that I mentioned
in my email but I didn't split any townlands (yet). It's a good point that
I don't need to split a townland border just because a parish or barony
border runs through it. As long as I assume that townlands do not add up to
parishes, then townlands can overlap two different parishes. (i.e. we can
run a parish border through the middle or a townland). I suppose this is ok
then. The townland "Lugaphuill" then is just oddly shaped as you say.

Can someone confirm that townlands do not necessarily add up to civil
parishes?

Well if we don't split townlands: Below is an example of where
"Druminracahill" townland IS split in two parts in OSM due to a civil
parish boundary. So should this very small split townland part be merged
with it's big brother?
https://www.openstreetmap.org/note/799934#map=18/53.83127/-9.26316=N

All all best,
Brian


On Sat, Dec 10, 2016 at 2:56 PM, Mark Tully  wrote:

> Hi Brian,
>
> My own opinion would be that townlands shouldn't be split in OSM and if
> they overlap parishes, then it's up to the software using the OSM data to
> figure out how to handle them.
>
> As far as I understand it, townlands don't necessarily add up to civil
> parishes, civil parishes don't necessarily add up to baronies and baronies
> don't necessarily add up to counties.  Furthermore, townlands don't
> necessarily add up to electoral divisions.  In rural areas, the GSGS3906
> map splits the townland into 2 pieces (e.g. Agall (ED Derrycoooly) and
> Agall (ED Screggan) at
> http://maps.openstreetmap.ie/?zoom=16=53.26048=-7.
> 59323=B00T,
> but in urban areas, it doesn't, it just cuts the ED (and town) boundary
> through the townland e.g.
> http://maps.openstreetmap.ie/?zoom=15=52.80303=-6.
> 73163=B00T.
> Make of that what you will!
>
> Regarding some of your specific issues:
> 3: I've come across several areas with CPs covering 2 non adjoining areas
> so this doesn't look that unusual e.g.:
> http://www.openstreetmap.org/relation/4280429
> 4: I think it's just awkwardly shaped.  Not sure if there's a boundary at
> the narrow part or not on
> http://maps.openstreetmap.ie/?zoom=16=53.8103=-9.
> 2563=B00T,
> but I don't see the name for the second townland on the GSGS3906 map if it
> is.
>
> Bear in mind that this is all just my own opinion and others may disagree.
>
> Hope this helps,
> Mark
>
> On Thu, 1 Dec 2016 at 22:05 Brian Tuffy  wrote:
>
> > Hi all,
> > I'm fairly new to OSM, I map under the username OscarBrownbread.
> > I have been mapping Castlebar and Co. Mayo. Recently I have been looking
> > more at townlands
> >
> > I have found many spelling errors in townland names (approx 10) in my
> > locality. Cross referencing them with the loganim data helped correct
> them.
> > Anyway, I now see many other challenges, I see many townlands that look
> > like they should be split. This is usually because of civil parishes
> (CPs)
> > or baronies going through them.
> >
> > Here are some of the issues I have come across in my area.
> > (0) townland spelling mistakes due to hard-to-read or missing letters in
> > the Brittish War Maps source
> > (1) Civil parish "Balla" missing
> > (2) CP "Mayo" is split into two parts, "Mayo (clanmorris portion)" and
> > "Mayo (kilmaine portion)" due to different baronies
> > (3) townland "Brownhall Demense" belonging to CP "Mayo" disconnected from
> > the rest of the CP (disconnected by the CP Balla which we still need to
> add
> > to OSM). This forms two closed ways in the boundary relation instead of
> > one.
> > (4) townland "Lugaphuill" really looks like it should be split in two
> > separate townlands with the same name that border eachother, but it is
> > currently one big townland in OSM. Now the name label (centroid) is in
> > another townland.
> > http://www.openstreetmap.org/#map=16/53.8103/-9.2563=N
> >
> > Ok, So I am Not looking for advice on how to solve each issue, that I can
> > try myself as I go forward. If you are curious, you can check out my OSM
> > map notes here.
> > http://www.openstreetmap.org/note/799945#map=13/53.7623/-9.1082=N
> .
> > But, I do need to know how to split townlands,
> >
> > My question is, Should we split townlands to make parish/barony borders
> > more accurate?
> > This results in townlands with the exact same name bordering eachother.
> > Wouldn't this result in confusion for search engines, programming
> database
> > etc. ?? Is it even possible to handle this?
> > If we do split them (as it is shown on the more recent maps), should we
> > name them differently? e.g. ballytown #1, ballytown #2 ?
> > Possibly, name= ballytown, name_official=ballytown#1 or something like
> > that?
> > I suppose we should rename but Townland names from the maps already
> contain
> > "north" "south" "east" "upper" "lower" etc. (BTW, anyone know why "upper"
> > is always to the south??)
> 

Re: [Talk-it] Riutilizzo informazioni PRG, PAT, PI in Openstreetmap

[Maurizio Napolitano]

2016-12-10 10:12 GMT+01:00 Alessandro Sarretta :
> Ciao a tutti,
>
> la domanda è abbastanza semplice: si possono utilizzare informazioni
> derivate dai pdf ufficali rilasciati dai Comuni per utilizzarle in
> Openstreetmap?

In teoria dato che sono documenti e atti rilasciati dalla pubblica
amministrazione,
questi sono in pubblico dominio
vedi articolo 5
http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:1941-04-22;633!vig=2016-12-11

"Le disposizioni di questa legge non si applicano ai testi degli atti
ufficiali dello stato e delle Amministrazioni pubbliche, sia italiane
che straniere. "

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

Re: [OSM-talk] Mozambique's living streets

[john whelan]

Which icon is it?  I was never very good at icons.

Thanks John

On 11 December 2016 at 07:58, Matthijs Melissen 
wrote:

> On 11 December 2016 at 01:15, Jean-Marc Liotier  wrote:
> > But participants
> > in the thread were mostly experienced with French-speaking Africa - so I
> > cannot rule out the existence of a living street legal classification in
> > other locales.
>
> At least South Africa seems to have legal living_streets:
> https://en.wikipedia.org/wiki/Road_signs_in_South_Africa#/
> media/File:SADC_road_sign_R403.svg
>
> -- Matthijs
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Re : Re: Mozambique's living streets

[Pierre Béland]

Quite warm in Jeremie, Haiti this morning. with last night rain I wont go 
measure streets with :)
Pierre

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le dim., 11, déc., 2016 « à » 7:58 AM, Matthijs 
Melissen a écrit :   On 11 December 2016 at 01:15, 
Jean-Marc Liotier  wrote:
> But participants
> in the thread were mostly experienced with French-speaking Africa - so I
> cannot rule out the existence of a living street legal classification in
> other locales.

At least South Africa seems to have legal living_streets:
https://en.wikipedia.org/wiki/Road_signs_in_South_Africa#/media/File:SADC_road_sign_R403.svg

-- Matthijs

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

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Garry]

Am 11.12.2016 um 12:24 schrieb Robert:

Hallo zusammen!

Ich habe eine kurze Frage. Wie würdet ihr eine Straße (800 m lang,
eine Spur je Richtung, keine bauliche Fahrbahntrennung) taggen, welche
zur Autobahn zuführt? Zu Beginn der Straße, also an der letzten
Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
Landesstraße.

Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
vorgefunden werden kann.

Danke für Eure Meinungen!

Hat die Straße noch eine andere Funktion außer "Autobahnauffahrt"?
D.h. dient sie auch als Zufahrt zu Forstwegen, Autobahnmeisterei o.ä.?
Wenn ausschließlich Autobahnzufahrt würde ich sie auf jeden Fall als 
motorway-link taggen um ganz klar darzustellen:
Hier geht es ausschließlich auf die Autobahn und Du hast hier nichts 
verloren wenn Dein Fahrzeug nicht für die Autobahn erlaubt ist.
Es geht ja vorrangig um die verkehrliche Bedeutung/Widmung und nicht 
darum, wer für den
Unterhalt zuständig ist. Und das wird ja in Deinem Fall eindeutig mit 
dem Zeichen 330.1 angezeigt.


Gerald


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

Re: [OSM-talk] Mozambique's living streets

[Matthijs Melissen]

On 11 December 2016 at 01:15, Jean-Marc Liotier  wrote:
> But participants
> in the thread were mostly experienced with French-speaking Africa - so I
> cannot rule out the existence of a living street legal classification in
> other locales.

At least South Africa seems to have legal living_streets:
https://en.wikipedia.org/wiki/Road_signs_in_South_Africa#/media/File:SADC_road_sign_R403.svg

-- Matthijs

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

Re: [Talk-es] Sobre importaciones y otros demonios

[A A]

Hola, aunque no tengo muchos conocimientos sobre el tema me voy a atrever a dar 
una idea:


Lo que se podría hacer es meter a mano aquellos datos que no estén en OSM con 
JOSM y las imágenes de fondo del catastro (pienso en calle, número de portal y 
código postal), omitiendo (al decir omitir me refiero a no introducir los 
datos) todo aquello que entre en conflicto con los ya existentes en OSM, por 
ejemplo si el nombre de la calle no coincide con los datos de OSM o si se ve 
que la numeración del catastro no tiene un orden correcto (faltan números de 
portal o los números pares e impares están en el mismo lado de la calle).


Yo he probado a hacer esto en mi pueblo (he de decir que es un pueblo pequeño, 
y esto unido al conocimiento de la zona me ayudó mucho) y creo que es factible 
siempre y cuando nos pongamos de acuerdo en como hacerlo y llevemos un orden y 
tengamos zonas asignadas como se planteó en su momento con la importación del 
catastro con herramientas como cat2osm. Creo que podría hacerse aunque no se 
conozca la zona, ya que al no incluir los datos que entren en conflicto con los 
que tenemos en OSM minimizaríamos al máximo los riesgos de hacerlo mal.


Espero que os guste la idea ;)


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

Re: [Talk-de] Tagging Zuführung zur Autobahn

[Rolf Eike Beer]

Am Sonntag 11 Dezember 2016, 12:24:02 schrieb Robert:
> Hallo zusammen!
> 
> Ich habe eine kurze Frage. Wie würdet ihr eine Straße (800 m lang,
> eine Spur je Richtung, keine bauliche Fahrbahntrennung) taggen, welche
> zur Autobahn zuführt? Zu Beginn der Straße, also an der letzten
> Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
> erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
> Landesstraße.
> 
> Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
> dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
> auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
> vorgefunden werden kann.

Eine völlig unrepresentative Stichprobe, die ich gerade entlang der A2 und A7 
gemacht habe, zeigt, dass das "nur der baulich je Fahrtrichtung getrennte 
Teil", über den du im Wiki vermutlich auch gestolpert bist, allgemein 
ignoriert wird. Ansonsten hätte ich nämlich auch gesagt, dass das definitiv 
trunk_link ist. Allerdings kenne ich den Hintergrund für die gegenteilige 
Festlegung nicht. Wenn ich mir die Talk-Seite zu 
https://wiki.openstreetmap.org/wiki/Highway_link ansehe scheint es mir jedoch, 
als wollte man das "ausfließen" der Farbe in die querende Straße damit 
verhindern.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Mozambique's living streets

[Martin Koppenhoefer]

sent from a phone

> On 11 Dec 2016, at 01:15, Jean-Marc Liotier  wrote:
> 
> The resulting consensus was that, while unpaved residential streets in Africa 
> are living streets in practice


which aspects of living streets? That you may only park in marked parking lots? 
That you'll always have to give way when coming from such a street? That 20km/h 
are more than legally allowed?

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

Re: [OSM-ja] 12/17 東京！街歩き！マッピングパーティ：第３回 小石川植物園

[yasunari yamashita]

山下です。
皆さんこんにちわ。

東京！街歩き！マッピングパーティ：第３回 小石川植物園
https://openstreetmap.connpass.com/event/45415/
は、いよいよ今度の土曜日。
皆さんの参加をお待ちしています！！

（関西では「今度」も「次」も同義語なのに、
　東京では「今度」と「次」が別な意味なことに
　昔、カルチャーショックをうけました：笑）


2016年11月20日 20:11 yasunari yamashita :
> 新宿の山下です。皆さんこんにちわ。
>
> 東京に引っ越して、3回目のマッピングパーティは
> 12/17（土）に小石川植物園。
>
> 東京！街歩き！マッピングパーティ：第３回 小石川植物園
> https://openstreetmap.connpass.com/event/45415/
>
> 皆様のご参加をお待ちしています！！
> --
> 山下康成＠東京都新宿区



-- 
山下康成＠東京都新宿区
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-de] Tagging Zuführung zur Autobahn

[Robert]

Hallo zusammen!

Ich habe eine kurze Frage. Wie würdet ihr eine Straße (800 m lang,
eine Spur je Richtung, keine bauliche Fahrbahntrennung) taggen, welche
zur Autobahn zuführt? Zu Beginn der Straße, also an der letzten
Kreuzung, steht das Zeichen 330.1 (Autobahn), im Gegenverkehr wird
erst dort per 330.2 die Autobahn beendet. Die Straße selbst ist eine
Landesstraße.

Aktuell ist sie als trunk+motorroad=yes getaggt, wobei motorroad=yes
dann bei Navis die Ansage "fahren Sie auf die Kraftfahrstraße"
auslösen könnte, was vor Ort mangels Zeichen 331 so ja nicht
vorgefunden werden kann.

Danke für Eure Meinungen!

Viele Grüße
Robert

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

Re: [Talk-cz] Trať 290 Olomouc - Šumperk - YouTube

[Michal Pustějovský]

Z těchto videí by se daly krásně odvozovat maximální 
rychlosti/signalizace. Hlavně na pohledzvlaku.cz to mají udělané opravdu 
krásně - vedle videa je i popis cesty se značkami a jejich polohou.


Michal


Dne 11.12.2016 v 1:38 Mikoláš Štrajt napsal(a):

K tomuto zdroji informací bych doplnil svůj oblíbený KIJ film.

Viz https://www.youtube.com/user/javdeluxe/videos

Videa označená jako KOKO jsou dokonce s komentářem tramvajáků. :-D

Jinak koukal jsem na nějaká videa podobného druhu z Ukrajiny a byla to 
celkem relaxační záležitost. 
Viz https://www.youtube.com/watch?v=WgMBkwLWrDU=PLZ9FyVZ0LT3dSGCLR8EPveLkdIE_j8lkE=3


Zdraví
--
Mikoláš Štrajt / Severák / http://severak.svita.cz/

-- Původní zpráva --
Od: Tomáš Tichý 
Komu: OpenStreetMap Czech Republic 
Datum: 10. 12. 2016 20:48:53
Předmět: Re: [Talk-cz] Trať 290 Olomouc - Šumperk - YouTube


Tady je jich taky pár :-)
http://pohledzvlaku.cz/

TT

On Sat, Dec 10, 2016 at 7:55 PM Ladislav Nesnera > wrote:

Railview.. :-D https://www.youtube.com/watch?v=nk53CfVnL9A

a tohle by mohl být také zajímavý typ zdroje -
https://www.youtube.com/watch?v=4K_mIsDf8uk (BTS? O:-) :-D )

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

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



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



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

Re: [OSM-talk-fr] intégration des référentiels STIF

[Noémie Lehuby]

Bonjour,

j'ai publié une première version d'un outil qui permet déjà de commencer 
le travail :

https://ref-lignes-stif.5apps.com/

Je continuerai de l'améliorer dans la semaine.
Noémie


Date: Tue, 6 Dec 2016 01:42:47 +0100
From: Jérôme Amagat 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:

Content-Type: text/plain; charset="utf-8"

Le 5 décembre 2016 à 21:49, Noémie Lehuby 
 a

écrit :


Bonsoir,

Pour les objets existants : http://taginfo.openstreetmap.f
r/keys/?key=ref:FR:STIF
à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif
http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif

Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations 
sans

composante géographique ?



Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout 
d'un
node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, 
ça

marche bien pour ajouter les arrêts de bus.


Parce que les lignes de transport, l'objet OSM qui correspond le plus, 
ça

sera la relation route_master (dont les éléments sont exclusivement
d'autres relations) et qui ne se représente pas bien sur une carte.



Dans osm, oui c'est une relation route_master qui représente la  ligne 
de

bus mais il faut y placer des relation type=route et route=bus comme
indiqué là : https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
On en crée une pour le trajet du bus à l’allée une autre pour le retour
(voir encore plein d'autres si la ligne de bus a des variantes) et 
après on

met c'est différentes relations dans une relation route_master qui
représente toute la ligne de bus.
Comme il faut mettre dans c'est relation les bon morceaux de route
qu'empruntent les bus je pense pas qu'osmose ou un autre outil puissent 
le

faire à notre place.



Et je préférerais qu'on commence par les lignes avant d'attaquer les 
point
d'arrêts et zones d'arrêts (un peu comme avec les adresses, où on 
commence
par faire matcher les communes, puis les rues). Ça permettra d'être 
plus

fin et d'éviter d'attribuer la référence de l'arrêt qui est en fait de
l'autre côté de la rue, voire de créer des arrêts parce qu'on en a 
deux
dans les données du STIF alors qu'il n'y a bien qu'un unique arrêt sur 
le

terrain.



Il y en a 2, un pour chaque coté de la route?
Osmose permet de placer un point exactement où le stif le place lui. et
comme il les place sur ce que j'ai vu bien 1 de chaque coté de la route 
il

n'y a pas de problème?
Comme dans les relations il faut mettre les arrêts, si il existent déjà 
je

pense que c'est plus simple.

Si je dis des bêtises n’hésitez pas à rectifier j'ai déjà toucher se 
genre
de relation quand elles existaient déjà mais j'en ai pas vraiment 
créer.




nlehuby

Date: Mon, 5 Dec 2016 20:48:17 +0100

From: Jérôme Amagat 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:

Content-Type: text/plain; charset="utf-8"


J'ai regardé un peu les données.
Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" 
(les

public_transport=platform dans osm) les coordonnées semble de bonne
qualité. (pour les noms par contre c'est pas homogène certains sont 
tout

en
majuscule d'autres non, avec bien sur des problèmes avec les accents 
non

présents sur les majuscules)
C'est un bon candidat pour osmose je pense. (les tags ajoutés 
seraient

public_transport=platform name=* et pour les arrêt de bus :
highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA)
possibilité
de créer une relation public_transport = stop_area qui regroupe des
platforms mais je sais pas pour lequel des 2 et c'est plus compliqué 
pour

osmose.

Par contre les ref: il y en a beaucoup dans les fichiers. je dirais 
qu'il
faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on 
sait

quel ref c'est.
par contre pour les arrêts, il y a un ID_REFA avec les "Zones
d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
"StopPoint:81:255"). c'est une partie des valeurs déjà présentent 
dans

osm.
Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et 
des

ref:FR:stif (http://overpass-turbo.eu/s/ktA)

Le 5 décembre 2016 à 08:49, Florian LAINEZ  a 
écrit :


Salut Noémie,
L'identifiant ref:FR:STIF me parait également le plus pérenne et 
donc il
devrait être préféré systématiquement. Ceci dit, il n'y a aucun 
problème

à
ajouter le code technique si cela peut t'être utile.

Il ne me semble pas choquant d'utiliser ref:FR:STIF pour identifier 
les

Re: [OSM-talk] Mozambique's living streets

[Tobias Zwick]

> from minor ones... Some bright spark took initiative by tagging a large
> part of Dakar's residential streets as highway=service - that has been
> universally perceived as a very bad idea.
Well, there is this line in the wiki for highway=service and service=alley:

"In some medieval European settlements alleys may be the very narrow
streets which run in-between buildings, providing public through-access.
" ( http://wiki.openstreetmap.org/wiki/Tag:service%3Dalley )

These kinds of streets are not only common in old town centers in Europe
but can be found in any place in the world that hadn't been built with
cars in mind, in shanty towns and also in modern (non-shanty) towns -
especially in Asia.

Now, the alley tag mentioned is problematic because there is no clear
definition what may still count as an alley and what should be a
residential road already.

Actually I raised the same issue 3 years ago in the forum
https://forum.openstreetmap.org/viewtopic.php?id=21942 (with links to
example imagery).
The outcome, more or less was:
* do not use living_street for non-living-streets
* use path/footway for anything that does not fit a car anymore (i.e.
only a motorcycle/rickshaw)
* use highway=service + service=alley for residential alleys that barely
fit a car if convenient
* otherwise residential for everything else, use width/lanes to give a
hint how wide it is

(Not saying that I am absolutely content about it, it is still ambiguous)

The existence of these discussions about how to tag really small
residential roads popping up and the living_street tagging being popular
where there is no such (legal) thing as a living street again and again
is a sign that there is an unalleviated uncertainty and thus room for
conflict and disagreement about this, since it is not clearly defined.

Now, talking about this is good. But can we solve and clear this up here
in the interest of all mappers and correct the ambiguities in the wiki
definition once and for all?

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

[Talk-GB] GB Coastline - PGS vs OS

[Colin Smale]

Hi, 

Most of the coastline is currently tagged as "source=PGS". As part of
the Boundary-Line open data set OS provide MHW lines which look to be
significantly better than the PGS data: 

* Much newer - updated twice a year, although I am not sure how old
the actual underlying survey data is (PGS coastlines seem to be from
2006)
* Better resolution - more nodes, smoother curves
* Consistent with admin boundary data, so MLW never appears above MHW
(often a problem on rocky coastlines like Wales and Cornwall)

There are a couple of caveats when working with the OS data: 

* Where MHW=MLW, i.e. the MHW is colinear with the admin boundary at
MLW, there is a gap in the MHW data
* The MHW data goes miles inland in tidal estuaries, which is correct
from the MHW standpoint, but for coastlines I think we need to cut
across the estuaries at the right point to form the correct baseline
* The MHW data is organised by area - down to constituency level.
Every time the line crosses the area boundary, it simply stops and you
need to load the adjacent area to continue the line

I have uploaded GPX versions of the October 2016 OS MHW data to
http://csmale.dev.openstreetmap.org/os_boundaryline/mhw/ with a file per
county / unitary area (I have not produced the files for the
higher-level regions or the lower-level constituency areas). 

In the Thames estuary around Southend and on the north Kent coast I have
replaced the PGS data with the new OS data and to me it looks much
better (in Potlatch) although the changes are not yet showing through on
"the map". I think coastline changes are processed less frequently. 

Any comments? 

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

Re: [OSM-talk-fr] installation troglodytique

[osm . sanspourriel]

quelques idées :

le plus évi*d*ent : level=-1

peut-être ajouter une possibilité à *building:architecture* 



building=underground

https://wiki.openstreetmap.org/wiki/FR:Cave

(mais avec man_made=yes)

tombe troglodyte  : tomb 
=rock-cut 



Et sinon regarder où il y a de tels habitats : 
https://fr.wikipedia.org/wiki/Habitat_troglodytique

Je suppose que la communauté OSM de Tunisie a réfléchi au problème.

Le 11/12/2016 à 10:12, ades_...@orange.fr - ades_...@orange.fr a écrit :

ça marche pas ;-)
Pour être plus précis, je cherche comment caractériser un établissement 
troglodytique, donc une cavité, ouverte de main d’homme, en plaine ou dans une 
falaise et dont l’usage (ancien ou actuel) peut être varié (habitat, commerce…).

Il s’agirait d’abord d’un tag équivalent à ‘building=yes’  sauf que ce n’est 
pas un bâtiment, mais un ensemble de trous à usage de bâtiment auquel 
pourraient effectivement être appliqués, le cas échéant, les tags que tu 
proposes, comme tout autre tag applicable à un bâtiment.

L’idée serait de disposer des tags nécessaires pour indiquer ce « bâtiment » en 
creux. Sans doute sur un point situé à l’entrée, un périmètre global de 
l’emprise  de l’établissement pourrait aussi être dessiné. Pour ce qui est de 
la disposition des pièces, c’est sans doute une autre question.
Suivant le  cas, le troglodyte s’organise autour d’une cour ou d’un cavage, 
l’accès se fait par une rampe, un puits ou une plateforme, ces éléments (avec 
les cheminées) sont des surfaces visible et donc des objets physiques 
cartographiables.

Reste à trouver les tags…


Le 10 déc. 2016 à 17:30, althio  a écrit :

Bonjour,

Je suggère d'utiliser le tag existant plus global :
historic=archaeological_site
https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Darchaeological_site

Pour détailler, il faudrait inventer un sous-tag site_type=*.
Pour coller encore à l'existant (historic=tomb ; tomb=rock-cut), je te propose
historic=archaeological_site
site_type=rock-cut

avec des options pour:
ruins=yes
tourism=yes
name="nom du site"
historic:civilization=*
historic:period=*
historic:era=*
start_date=*
...

Je serai ravi d'avoir ton retour, pour savoir si cela te semble assez
détaillé et correspondre à la situation.

-- althio


2016-12-08 10:12 GMT+01:00 ades_...@orange.fr :

bonjour,
comment taguer un habitat ou une installation troglodytique ?

taginfo ne renvoie que des occurrences associées au champ ‘name’.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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


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

[Talk-TW] QGIS OSM 相關 Plugin 翻譯

[Dennis Raylin Chen]

Dear all

QGIS 除了內建下載 OSM 資料的功能，還有幾個跟 OSM 相關的 plugin，如 OpenLayer，或是簡化OSM 資料處理的
QuickOSM。

QGIS 上面跟 OSM 相關的功能介面翻譯是用 Transifex 之外，plugin 介面翻譯通常是在 Github 處理

我目前先把兩個 plugin 的翻譯 fork 到 OsmHackTW 的 Github 頁面

QuickOSM 繁中翻譯
https://github.com/OsmHackTW/QuickOSM/tree/master/i18n
翻譯了幾筆了，還需要時間處理

OpenLayer 繁中翻譯
https://github.com/OsmHackTW/qgis-openlayers-plugin
先fork過來，還未動手

如果有人能共襄盛舉一起來翻譯就會更好，一起處理為數相當多 OpenStreetMap 程式、文件、外部服務翻譯在地化

Dennis
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [OSM-talk] Mozambique's living streets

[Oleksiy Muzalyev]

On 11.12.16 01:15, Jean-Marc Liotier wrote:

On 12/10/2016 08:47 PM, john whelan wrote:
I just did a search on part of Mozambique and came across more than 
500 highway=living_street.


I always understood them to be a European concept highway with signs 
on the street and a very low max speed.  I wouldn't have expected to 
see so many clustered together in Mozambique.


Idle curiosity are they a legal entity in Mozambique and other parts 
of Africa?


A while ago 
(https://lists.openstreetmap.org/pipermail/talk-fr/2013-August/061580.html) 
I started a thread about usage of highway=living_street in Africa. The 
resulting consensus was that, while unpaved residential streets in 
Africa are living streets in practice, they are not legally classified 
that way - and therefore the correct tagging is highway=residential... 
But participants in the thread were mostly experienced with 
French-speaking Africa - so I cannot rule out the existence of a 
living street legal classification in other locales.




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


Another possibility is a combination:

highway=service plus service=alley

https://wiki.openstreetmap.org/wiki/Tag:service%3Dalley

for example here: 
http://www.openstreetmap.org/way/230413004#map=14/46.6890/31.1548


These are not really residential streets like in a city, which are a 
shown on the map with strong lines.



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

[OSM-talk-fr] installation troglodytique

[ades_...@orange.fr]

ça marche pas ;-)
Pour être plus précis, je cherche comment caractériser un établissement 
troglodytique, donc une cavité, ouverte de main d’homme, en plaine ou dans une 
falaise et dont l’usage (ancien ou actuel) peut être varié (habitat, commerce…).

Il s’agirait d’abord d’un tag équivalent à ‘building=yes’  sauf que ce n’est 
pas un bâtiment, mais un ensemble de trous à usage de bâtiment auquel 
pourraient effectivement être appliqués, le cas échéant, les tags que tu 
proposes, comme tout autre tag applicable à un bâtiment.

L’idée serait de disposer des tags nécessaires pour indiquer ce « bâtiment » en 
creux. Sans doute sur un point situé à l’entrée, un périmètre global de 
l’emprise  de l’établissement pourrait aussi être dessiné. Pour ce qui est de 
la disposition des pièces, c’est sans doute une autre question. 
Suivant le  cas, le troglodyte s’organise autour d’une cour ou d’un cavage, 
l’accès se fait par une rampe, un puits ou une plateforme, ces éléments (avec 
les cheminées) sont des surfaces visible et donc des objets physiques 
cartographiables.

Reste à trouver les tags…

> Le 10 déc. 2016 à 17:30, althio  a écrit :
> 
> Bonjour,
> 
> Je suggère d'utiliser le tag existant plus global :
> historic=archaeological_site
> https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Darchaeological_site
> 
> Pour détailler, il faudrait inventer un sous-tag site_type=*.
> Pour coller encore à l'existant (historic=tomb ; tomb=rock-cut), je te propose
> historic=archaeological_site
> site_type=rock-cut
> 
> avec des options pour:
> ruins=yes
> tourism=yes
> name="nom du site"
> historic:civilization=*
> historic:period=*
> historic:era=*
> start_date=*
> ...
> 
> Je serai ravi d'avoir ton retour, pour savoir si cela te semble assez
> détaillé et correspondre à la situation.
> 
> -- althio
> 
> 
> 2016-12-08 10:12 GMT+01:00 ades_...@orange.fr :
>> bonjour,
>> comment taguer un habitat ou une installation troglodytique ?
>> 
>> taginfo ne renvoie que des occurrences associées au champ ‘name’.
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr

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