date:20110907

On 7 September 2011 16:31, Ian Sergeant ina...@gmail.com wrote:
 The Princes Highway is an historical curiosity, and internal name management
 name assigned by the NSW roads authority, and the name of a bunch of roads
 between Sydney and Adelaide.

 It isn't a route any longer.

It's still a series of non-contiguous sections that is named, these
sections belong as part of a route.

 I'm sure people say they are going to drive the Princes Highway from Sydney
 to Melbourne, but you can never pin it down to actual set of roads.  They
 just mean they are driving down the coast, as opposed to the Hume.  It is a
 useful turn of phrase, but it is a mapping anachronism.

The majority of the route, distance wise, would still exist as it has
for a long time.

 As I said, I'll leave it be, but the chance that this will be developed into
 something meaningful, is zip.

That's a very subjective thing to say, you claim it has no value,
others have obviously disagreed, the main thing to take into account
is what actual harm does it do to the map to exist as a relation, I
say none, so far your suggested examples of harm are imho wrong also
since the way should take precedence over any relation, this way you
can give streets local names and the route sharing the same physical
way can be shown where there no longer is a local route needing to be
shown.

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

On 7 September 2011 15:49, Ian Sergeant ina...@gmail.com wrote:
 I write  I just have something against this relation, because it is
 arbitrary and confusing

 and you write So your entire argument is that we should delete the whole
 route because it isn't contiguous?

Most routes are arbitrary and confusing, you only have to look at
rural/regional highways going through medium sized towns, this goes
doubly so for tourism routes and is again a very good reason for
having routes, rather than removing them.

 If that was my entire argument, I'd just say that, but instead of that I
 said that it is arbitrary and confusing.  Arbitrary because there is no
 touchstone of verifiability, it is just each person opinion.  Confusing,

The problem usually stems from differences at how the way is gazetted
to how the way is actually built, and for what ever reason the
gazetted version then isn't updated is another argument altogether.

 because it is both a road name and a route, and it is impossible for them
 both to align.  If this gets into a satnav which recommends you continue on
 the Princes Highway route, while actually turning off the Princes Highway
 road - what a mess.  Why do we seek this?

Way names are supposed to have preference, and if you are talking
about local routes that differ in name this shouldn't be an issue and
is one of the reasons to put highway names into routes.

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

On 7 September 2011 15:19, Ian Sergeant ina...@gmail.com wrote:

 Nah, that is all good to me.  I've got nothing against relations.  Nothing
 against routes.  Nothing against multiple relations and multiple routes. In
 fact, I'd have nothing against a parent relation that linked the sections of
 the National Route 1 and the diversionary highway routes, like State Highway
 60 - at least that is well defined.

 I just have something against this relation, because it is arbitrary and
 confusing.

So your entire argument is that we should delete the whole route
because it isn't contiguous?

Most, if not all routes won't be contiguous, Ross pointed this out the
other day but there is often on/off ramps, roads going from dual to
single carriage way and back again, then you also have roundabouts,
there is all sorts of reasons why gaps exists, but that is even more
reason to have routes for them, so that the bits that are named
Princess Highway can be tagged as such, and if bits are included that
shouldn't be then remove the bits not the entire route.

 I really think verifiability is the key for routes, if we start adding stuff
 to the map that isn't on the ground or can't be verified...

That may be a goal, but it doesn't mean it should be the only one, the
process of mapping is one of going from some information to better
information, and this is a continual process as things change over
time, not just the fact that better sources of data can be mapped
from.

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Charleville, Qld survey suggestions sought

On 7 September 2011 13:09, Christopher Barham cbar...@pobox.com wrote:
 Hi,
 I'm in Charleville, Qld for a couple of days with an iPhone, a garmin oregon 
 GPS and, from tomorrow, a vehicle.
 The place is pretty much unsurveyed, but the DCDB has been used to add 
 streets so the road geometry is ok.
 Will do what I can (street names etc) , but I wondered if there is anything 
 you guys could suggest would benefit from a survey around and about... maybe 
 further out from the town itself?

If memory serves correctly there is a weather museum/attraction at
Charleville, at a guess it'd be near the airport.

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread Liz

On Wed, 7 Sep 2011 16:31:38 +1000
Ian Sergeant ina...@gmail.com wrote:

 The Princes Highway is an historical curiosity, and internal name
 management name assigned by the NSW roads authority, and the name of
 a bunch of roads between Sydney and Adelaide.
 
 It isn't a route any longer.
 
 I'm sure people say they are going to drive the Princes Highway from
 Sydney to Melbourne, but you can never pin it down to actual set of
 roads.  They just mean they are driving down the coast, as opposed to
 the Hume.  It is a useful turn of phrase, but it is a mapping
 anachronism.

So you would be happier if there was a fourth dimension n the data,
that of time?
So that you could mark a route as 'original princes highway'
and another route as 'princes highway 1990' and so on?

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread Ian Sergeant

I wrote:
 This is why route numbers were invented.  So routes can be followed across
 multiple road names.  The route numbers are on the ground, or otherwise
 discoverable.

On Sep 6, 2011 3:02 PM, Steve Bennett stevag...@gmail.com wrote:
 I'm not sure if we're disagreeing or not, but: assuming that there is
 an uncontroversial route number of some sequence of roads, then we
 should have a relation describing that same sequence of roads. ref=*
 tags on ways are ok; relations are better.

 Do you agree with that? Or are you contesting the actual value of
relations?

Yes.  If there is an uncontroversial route number that applies to a sequence
of roads, lets map it.  Yes, a relation is the best way.

The issue I have is with using a route relation with a road name to link
split parts of a named road, and including roads that don't have a name or
alternate name in common with the route, and can't clearly be identified as
part of that route by survey.

My example of the Princes Highway route from Sydney to Adelaide currently is
one such route, where choosing what roads to include is often arbitary, and
even if completed it may still not be a through route that can be followed,
and may be confused with the actual road with the same name.

I have no problem with the A10, A1, MR1, M1 etc being used on route
relations.  I wouldn't even have a problem with multiple Princes Highway
routes over sections where such a route is clear and verifiable.

Ian.
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread John Henderson


On 08/09/11 07:58, Ian Sergeant wrote:


The issue I have is with using a route relation with a road name to
link split parts of a named road, and including roads that don't
have a name or alternate name in common with the route, and can't
clearly be identified as part of that route by survey.


I take a pragmatic approach, something like this:

Given my local knowledge, and being on-site, how would I direct somebody
who is unfamiliar with the exact route but wants to be given
turn-by-turn directions from A to a distant B.

I've been mapping routes like the Hume and Hovell Walking Track.  This
includes unnamed paths, named roads and highways, and things like
roundabouts (unnamed, of course).  But they all form part of the track
nevertheless.

Sometimes the precise route is unclear.  It doesn't really matter if I
can make a safe and convenient choice for a routing algorithm to follow.
If someone else knows better, I'm delighted for them to refine the route.

John H

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread Ian Sergeant


I wrote:


I'm sure people say they are going to drive the Princes Highway from
Sydney to Melbourne, but you can never pin it down to actual set of
roads.  They just mean they are driving down the coast, as opposed to
the Hume.  It is a useful turn of phrase, but it is a mapping
anachronism.


On 07/09/11 21:00, Liz wrote:

So you would be happier if there was a fourth dimension n the data,
that of time?
So that you could mark a route as 'original princes highway'
and another route as 'princes highway 1990' and so on?

Well, we have railway=abandoned, so perhaps we need a route=abandoned?

Seriously though, no.  I'm still sticking to verifiability being a 
touchstone of OSM, and necessary given the nature of our community 
project.  We can't each just go and make a route where we feel there 
should be one, without reasoning or evidence, and the try on the 
doesn't do any harm defence as a justification for its continued 
existence.


Similar to HIghway 1.  Probably as much in the Australian psyche as 
Route 66 is in the U.S, but routings and markings change, and we need to 
mark up the references on the ground.  We can't mark a way as Highway 1 
just because it had that cute sign pinned to a pole back in the 60s.


I'm sure we are interested in the history of the development of the road 
network, but I'm not sure our database is the place for the information 
right now.  Of course, in 100 years time, if we do our jobs properly, 
someone will have a nice historical reference of the same.


Anyway, much to the relief of all, I really will stop pushing this now.  
My last word on the issue.


Ian.

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread Steve Bennett

On Wed, Sep 7, 2011 at 12:27 PM, Ian Sergeant inas66+...@gmail.com wrote:
 An actual connected route along roads on the ground in this instance either
 doesn't exist or cannot be determined from any verifiable source.

 OSM requires verifiability, for reasons I consider apparent.  A route
 relation requires that there be an actual, connected route.

A route is by definition an abstraction. It is an idea dreamed up by a
committee somewhere, connecting various pieces of physical
infrastructure. It can then be communicated in various ways: with
physical signage, websites, pamphlets, maybe even legislation. However
it's communicated, interpretation is required to work out which roads
are in and which are out.

Steve

___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Princes Highway (Relation 538443)

2011-09-07 Thread Mark Pulley


Quoting Ian Sergeant ina...@gmail.com:


I'm sure we are interested in the history of the development of the
road network, but I'm not sure our database is the place for the
information right now.


For those interested, a partial history of the development of Highway  
1 is at Ozroads:


http://www.ozroads.com.au/NationalSystem/highway1.htm

Mark P.



___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-br] Criando nós (nodes)

2011-09-07 Thread Claudomiro Nascimento Junior

Se não me engano, acho que se vc baixar as areas que editou no JOSM é
possivel selecionar os nós criados pelo seu usuário -

Não é difícil editar 3 mil nós - Se vc chegou a mover uma rodovia extensa ou
rio, podem ser centenas de nós alterados num unico comando.

2011/9/6 Alexandre Parente Lima alexandre.pare...@gmail.com

 Ola

 Estava eu brincando no site do http://osmfight.neis-one.org/  , quando vi
 que meu usuário criou mais de 3000 nós.
 Seguramente não criei isso tudo, então acredito que tenho feito alguma
 bobagem com JOSM.
 Como posso verificar isso?

 Alexandre Parente Lima
 --
 Doutor em Ciências Ocultas, Filosofia Dramática, *Pediatria Charlatânica*
 , *Biologia Dogmática* e Astrologia Eletrônica.

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


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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Georg Feddern


Moin,

Albrecht Will schrieb:
Trotzdem sollten die planmäßigen 
Windschutzstreifen nach zahlreichen Flurneuordnungen im Zuge der Ausbildung 
landw. Großproduktion (LPG, Schläge über 300 ha und mehr ) in der damaligen 
DDR ein besonderes tag bekommen.
  


hmm, wodurch unterscheiden sie sich denn von sonstigen (kleineren) 
Windschutzstreifen (Knicks) wie z. B. hier in der Probstei?
Sowohl die Funktion als auch das Material ist doch das gleiche - einzig 
die Größe ist unterschiedlich.
Sollen die planmäßigen Landwirtschaftsflächen im Zuge der Ausbildung 
landw. Großproduktion (LPG, Schläge über 300 ha und mehr ) in der 
damaligen DDR dann auch ein besonderes tag bekommen?.


Es ist doch einzig eine Frage der Größe - und somit je nach 
Auflösungsvermögen (hier insbesondere in der Breite) nur die Frage ob 
eben Linie oder eben Fläche.


Wenn man eine Funktion beschreiben will, soll man ein tag für Funktion 
vergeben.
Wenn man dass Aussehen (Physis) beschreiben will, soll man ein Tag für 
eben dieses vergeben.
Wenn man eine Nutzung beschreiben will soll man ein tag für die Nutzung 
vergeben.


Aber dieses ein Haupt-Tag für alle gemeinsamen Ausprägungen ist in 
meinen Augen nicht zielführend - weder beim Mappen noch beim Auswerten.


Gruß
Georg



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

Re: [Talk-de] Srtm2OSM unter linux


On 2011-09-06 21:24, Henning Scholland wrote:

Hallo,
ist dir bekannt, dass es auf der Seite der OpenMTBMap auch fertige
Höhenlinien direkt als Garminkarte gibt?


Wenn ich mich da durch klicke lande ich immer auf der members Seite, die 
Geld von mir wollen.
Und meinen Ausschnitt haben die auch ned (jedenfalls ned so, wie ich 
gesehen habe).
Auch will ich selber mal ne Karte basteln, der Server langweilt sich 
schon so...



Henning


MfG,
Lars Schimmer
--
-
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] WDYE jetzt mit Zoom

2011-09-07 Thread Fabian Patzke

Danke sieht super aus, und man kann seine Editier-Historie jetzt noch besser
verfolgen. Interessant finde ich auch den Vergleich zu
http://yosmhm.neis-one.org/ sie haben durchaus andere Ansätze und anderen
Nutzen. Außerdem merke ich, das bei yosmhm einige meiner Änderungen nicht
angezeigt werden, die bei Deinem Tool beachtet werden. Ich schätze mal Du
hast die Karte extra recht klein gewählt, oder nicht?. Alles in allem schön
geworden. Danke.

--
View this message in context: 
http://gis.638310.n2.nabble.com/WDYE-jetzt-mit-Zoom-tp6765809p6766794.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Steffen Heinz


Am 07.09.2011 02:31, schrieb Wolfgang:

Hallo,
Am Dienstag 06 September 2011 17:15:30 schrieb Steffen Heinz:

  Hecke heißt ja nicht unbedingt ordentlich ;)
  http://de.wikipedia.org/wiki/Hecke
  und auch
  http://de.wikipedia.org/wiki/Benjeshecke

oder auch:

http://de.wikipedia.org/wiki/Knick

eine Sonderform, die eben keine Hecke im herkömmlichen Sinn ist, die hat
nämlich nicht den typischen Wall.
ic vermute mal das der Wall nicht mit Absicht angelegt wurde sndern 
einfach entstanden ist. Selbst unter Wiesenzäunen git es oft eine 
leichte Erhebung.
wenn hier eine Hecke geseitigt wurde ist deutlich noch eine Erhebung zu 
sehen, solange nicht gepflügt wird.





Wenn du die Benjeshecke auch gesondert taggen willst, tu dir keinen Zwang an


hätte ich hier in der Gegend nicht ;)



Grüße aus der Eifel
Steffen

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Jörk


moin,


Am 07.09.2011 09:27, schrieb Steffen Heinz:
ic vermute mal das der Wall nicht mit Absicht angelegt wurde sndern 
einfach entstanden ist. Selbst unter Wiesenzäunen git es oft eine 
leichte Erhebung.
wenn hier eine Hecke geseitigt wurde ist deutlich noch eine Erhebung 
zu sehen, solange nicht gepflügt wird. 


Falsch, bei einem Knick (in Schleswig-Holstein) ist der Wall absichtlich 
angelegt - so etwa 1m hoch und 2m breit...


VG

Jörk


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

Re: [Talk-de] Srtm2OSM unter linux

2011-09-07 Thread Andreas Tille

On Tue, Sep 06, 2011 at 09:24:49PM +0200, Henning Scholland wrote:
 Hallo,
 ist dir bekannt, dass es auf der Seite der OpenMTBMap auch fertige  
 Höhenlinien direkt als Garminkarte gibt?

Das es die *direkt* als Garmin-Karte gibt, ist mir so nicht bekannt -
sofern dieses direkt meint, daß es in das gmapsupp.img integriert wird.

In der Anleitung[1] steht auch explizit:

  Achtung, das macht eigentlich nur Sinn, wenn man ein neues GPS
  benutzt, wo man die gmapsupp.img beliebig umbenennen kann, und somit
  mehrere gmapsupp.img im /Garmin Ordner haben kann

Das ist bei meinem Garmin Etrex Vista leider nicht der Fall und ich
suche noch nach einer Möglichkeit, die Höhenlinien direkt in das
gmapsupp.img hineinzumurkeln.

Viele Grüße

   Andreas.

[1] http://openmtbmap.org/de/about-2/openmtbmaps-contourlines/

-- 
http://fam-tille.de

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Falk Zscheile

Euer Heckenstreit verlangt förmlich nach einem sub-Tag. Ich denke im
wesentlichen Einig ist sich die Runde, dass es verschiedene Formen von
Hecken gibt. Von der geschnittenen im Vorgarten, über solche zum
Schutz von Feldern (Knicks in S-H, Buchenhecken in der Eifel) bis hin
zu solchen, die erst noch eine richtige werden soll Benjeshecke.

Macht ein barrier=hedge dann weiß erst einmal jeder was gemeint ist
(auch außerhalb von Deutschland). Jeder der mehr in der Landschaft
sieht als das ist eine Hecke kann dann ohne weiteres ein sub-Tag
ergänzen und dort kann sich jeder austoben und seine Knicks,
Benjeshecken, LPG-Hecken oder was auch immer verwursten. Auch den
Leuten, welche die Daten auswerten macht man es so einfacher, als wenn
die erst einmal recherchieren müssen ob eine Hecke am Feld in S-H
anders heißt als in M-V oder in der Eifel. Und im Falle eines
Kleinkrieges über die richtige Einordnung einer Hecke bleibt zumindest
das übergeordnete Tag gleich und der Datenbestand brauchbar.

Gruß, Falk

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

Re: [Talk-de] Srtm2OSM unter linux

2011-09-07 Thread Carsten Schwede


Hallihallo,

Am 07.09.2011 10:11, schrieb Andreas Tille:

Das ist bei meinem Garmin Etrex Vista leider nicht der Fall und ich
suche noch nach einer Möglichkeit, die Höhenlinien direkt in das
gmapsupp.img hineinzumurkeln.


Na das ist aber doch einfach. Hole Dir bei der openmtbmap die 
Höhenlinien ohne Installer, die Du brauchst, dann packe diese alle in 
ein Verzeichnis am Besten mit Deinen Karten, die Du noch benötigst und 
das Ganze kannst Du dann per mkgmap zusammenführen:


java -jar mkgmap.jar --gmapsupp *.img

Das ist dann eine gmapsupp wo alles durcheinandergewürfelt drin ist und 
nix einfach abschaltbar ist, aber es funktioniert schonmal. Die 
komfortablere Lösung geht über Installation ins Kartenprogramm, hier 
auch die Pakete jeweils downloaden, mittels mkgmap für jedes Paket eine 
tdb- und eine Übersichts- Datei erzeugen,


java -jar mkgmap.jar --overview-mapname=SRTM Deutschland 
--series-name=SRTM_DE --family-name=SRTM DE --family-name=SRTM DE 
--description=SRTM --tdbfile *.img


dann in QLandkarte laden und die Kacheln die Du brauchst aus allen 
installierten Karten auswählen und zu einer gmapsupp zusammenfügen. Ist 
doch eigentlich gar nicht so schwer. :-)



--
Viele Gruesse
Computerteddy

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Albrecht Will

Am Dienstag 06 September 2011, 17:01:13 schrieb Martin Koppenhoefer:
 Den Weg oder Graben würde ich auch nicht als Gebüsch taggen, wenn es
 denn keines ist.

Hallo Martin,

klar, ich hatte im Hintergrund die Kombination Weg/Bach + Gehölz
 
  Jeder
  Waldrand fängt so an und ist kein scrub.
 
 wieso nicht? Wenn man will kann man das m.E. sehr wohl in den
 Bereichen so taggen, wo noch keine Bäume stehen aber Gestrüpp
 vorhanden ist.

Details in der Natur haben grundsätzlich das Problem, daß sie sich in 
überschaubarer Zeit ändern. Nimm z.B. Waldwege. Wenn Du einen häufig genutzten 
Weg siehst, kannst Du die Konstruktion erkennen, also meinetwegen Schotter. 
Der gleiche Untergrund um die Ecke wird wegen starken Bewuchses nicht mehr 
wahrgenommen. Welchen grade setzt Du dann an (wobei Einheimische und 
Kurzbesucher sicher sehr unterschiedliches sehen)? Ein heute schlecht 
nutzbarer Weg kann bei der nächsten Holzabfuhr wieder seine alte Breite und 
Erkennbarkeit angenommen haben. Die Erkennbarkeit von Wegen kann auch von der 
Jahreszeit abhängen. Ich bevorzuge daher in solchem Fall eher die latenten 
Möglichkeiten des Weges und gebe Zusatzinfos zur Erkennbarkeit oder smoothnes. 
Jemand, der mit Karten in der Natur umgeht, weiß, in welchen von-bis-Bereichen 
ein Zustand schwanken kann, egal ob Wege oder Waldränder oder Gehözstreifen. 
Zu viele Details erzeugen einen zusätzlichen Druck.

Hier noch zur Rückfrage zu Pionierpflanzen/Ruderalflora, weil es zum Thema 
Detailtiefe paßt. Wenn das Gebiet lange genug in Ruhe gelassen wird, siehst Du 
plötzlich Wald. Ich werden meine 20 Jahre alten scrub-Flächen wohl sukzessive 
dahin umwandeln müssen.
(Da muß ich wohl noch ein Problem anstoßen. Unser zumeist forstlich genutzter 
Wald ist durch Gestelle/Wege in Jagen unterteilt. Die Eigenschaften der Jagen 
ändern sich - Alter, Baumart, Dichte  Um das darzustellen müßte die 
bisherige Darstellung - ein großes Waldgebiet - aus einem Mosaik 
zusammengesetzt werden, oder? Und wer behält das im Auge? Gibt es in späteren 
Jahren Mapper, die Fortschreibungen als Aufgabe sehen und annehmen?)
 
  Was hältst Du von einer Abwandlung der Allee für diesen Zweck nach Art
  der TOP-Karten?
 
 einen Allee-tag und dann einen Untertag dafür für Gebüsch würde ich
 eher nicht machen, schon gar nicht bei Bächen, für die Du es ja auch
 haben willst. Dann lieber einen Tag für Gebüsch erfinden, aber den
 gibts ja schon. Für Hecken gibts auch schon was. ;-)
 
 Ich würde lieber verschiedene allgemeine Tags gleichzeitig zur
 Anwendung bringen als jeweils einen superspezifischen Tag zu nehmen,
 der dann die physisch gleiche Situation jeweils nach anderen
 Kritierien / Blickwinkeln beschreibt. Solange sich die Namensräume bei
 letzterem nicht in die Quere kommen (man also einen dem spezifischen
 Kriterium angemessenen spezifischen Key benutzt) kann man das aber
 auch machen.

Nachdem ich oben für Beschränkung plädiert habe stimme ich Dir im Prinzip zu.
Laß uns aber doch einfach die eingeführte Symbolik der Geografen im Auge 
behalten. Wenn die Allee durch eine einreihige Perlenschnur von Kullern 
parallel zur Straße dargestellt wird, dann ist es doch nicht weit entfernt, 
noch eine oder zwei Reihen von kleineren Kullern daneben zu führen und sie für 
eine linienförmige Gehölzfläche zu nutzen. Beim Blick auf die Karte darf sich 
dann jeder ausmalen, wie dicht oder hoch oder breit der Streifen ist. Ich 
denke, das ist nicht superspeziell.
Während in der Magdeburger Börde von den alten Gehölzstreifen oder auch ein- 
und zweiseitigen (Obst) Bepflanzungen kaum noch was übrig ist, haben meine 
Vormapper in meiner Gegend genau die Grünstreifen (die es hier noch reichlich 
gibt und die Landschaft zum Glück prägen) übrig gelassen. Was mache ich mit 
den weißen Streifen? In der Mitte ist ein Bach. 
Ach ja Bach oder Graben, das ist ein besonderes Problem. Zwei mehr oder 
weniger breite Böschungen, eine mehr oder weniger breite Sohle, links oder 
rechts ein Bewirtschaftungsstreifen (und meine Gehölzreihen oder -flächen). 
Dafür hat der Flächenmapper Platz gelassen. Eine Lösungsvariante wäre für 
mich, landuse mit dem Gewässer zu koppeln und die oben erwähnten Kullern 
parallel zum Gewässer darüber zu setzen. Abeeer: Gewässer und Wege haben 
vielfach eigene Eigentumsverhältnisse  Stellen wir Topografie mittels 
allgemein verbreiteter Symbolik dar oder machen wir GIS? Inzwischen scheint 
OSM wohl ein Hybrid zu sein. 
Um Regeldiskussionen ist deshlab wohl nicht drumrumzukommen. 
Nicht ganz zufällig sind wir damit in der Nähe einer anderen laaangen 
Diskussion zur Koppung von Straße und benachbartem landuse. Die ist schon 
sinnvoll, sollte nach meinem Geschmack aber besser mündlich geführt werden und 
eine Grundvorausetzung im Auge behalten, wohin soll/will sich OSM entwickeln.

Ich habe jetzt mehrere unterschiedliche Dinge erwähnt, daß ich fürchte, die 
Diskussion geht furchtbar in die Breite und Länge. 

Gruß
Albrecht

[Talk-de] OSM-Karte Andre Joost

2011-09-07 Thread Wolfgang Wienke


Hallo Andre!
Da ich annehme, Andre Jost über andre+j...@nurfuerspam.de nicht 
erreichen zu können auf diesem öffentlichem Wege:

Ich habe http://powerland.bplaced.net./osm-power.htm
im OSM-Wiki auf der Liste der Tileserver eingetragen. Ich hoffe, das war 
ok. Falls es dort rechtliche Beschränkungen gibt bitte entsprechend 
nachtragen!

--
   Mit freundlichen Gruessen

 Wolfgang Wienke

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

Re: [Talk-de] Frage bez. Kacheln


On 2011-09-06 19:04, ant wrote:

On 06.09.2011 18:27, ant wrote:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm


Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp
kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes
überschrieben werden:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted
--write-xml merged.osm


Hm, das Osmosis 0.39 meckert da aber fleissig:
task type read-xml-0.5 not existant
task type --migrate not existant...



Grüße
ant


MfG,
Lars Schimmer
--
-
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Frage bez. Kacheln


On 2011-09-07 10:49, Lars Schimmer wrote:

On 2011-09-06 19:04, ant wrote:

On 06.09.2011 18:27, ant wrote:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm


Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp
kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes
überschrieben werden:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted
--write-xml merged.osm


Hm, das Osmosis 0.39 meckert da aber fleissig:
task type read-xml-0.5 not existant
task type --migrate not existant...


Ha, Osmosis ist zu aktuell, der kann kein migrate mehr und ich hab da 
noch alte 0.5 Daten im Auszug, also mal suchen...



Grüße
ant


MfG,
Lars Schimmer



MfG,
Lars Schimmer
--
-
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Frage bez. Kacheln

2011-09-07 Thread Igor Podolskiy

Hallo Lars,

 Ha, Osmosis ist zu aktuell, der kann kein migrate mehr und ich hab da
 noch alte 0.5 Daten im Auszug, also mal suchen...

Du könntest Osmosis 0.35 nehmen (die letzte Version, die API 0.5 konnte), damit 
die Migration machen und dann mit 0.39 weiterarbeiten.

Ciao
Igor
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Albrecht Will

Moin Georg,

auch wenn es manchen Diskutanten so scheint, als wollte ich einen regionalen 
Spezialtag für linienhafte Gehölze erstreiten. 
Neeeiiinnn!

Ich halte linienhafte Gehölzstreifen in unscharfer Breite aber für den 
Oberbegriff. Darunter gibt es regionale und/oder historische Ausprägungen, die 
dann auch noch verschiedene Zwecke erfüllen. (Extremfall: fein säuberlich 
geschnittene Hecken sogar noch mit Formen und Figuren)
Deiner Sortierung nach Funktion, Aussehen und Nutzung stimme gern zu, würde 
als Kartograph die Physis jedoch gern an erster Stelle sehen. Wir stellen ja 
auch zuerst das Gebäude dar und vergeben dann Eigenschaften. Oder andersrum 
wir nehmen erst das Äußere(Kategorie) wahr und spezifizieren danach.

Gruß
Albrecht

Am Mittwoch 07 September 2011, 09:03:15 schrieb Georg Feddern:
 Moin,
 
 Albrecht Will schrieb:
  Trotzdem sollten die planmäßigen
  Windschutzstreifen nach zahlreichen Flurneuordnungen im Zuge der
  Ausbildung landw. Großproduktion (LPG, Schläge über 300 ha und mehr ) in
  der damaligen DDR ein besonderes tag bekommen.
 
 hmm, wodurch unterscheiden sie sich denn von sonstigen (kleineren)
 Windschutzstreifen (Knicks) wie z. B. hier in der Probstei?
 Sowohl die Funktion als auch das Material ist doch das gleiche - einzig
 die Größe ist unterschiedlich.
 Sollen die planmäßigen Landwirtschaftsflächen im Zuge der Ausbildung
 landw. Großproduktion (LPG, Schläge über 300 ha und mehr ) in der
 damaligen DDR dann auch ein besonderes tag bekommen?.
 
 Es ist doch einzig eine Frage der Größe - und somit je nach
 Auflösungsvermögen (hier insbesondere in der Breite) nur die Frage ob
 eben Linie oder eben Fläche.
 
 Wenn man eine Funktion beschreiben will, soll man ein tag für Funktion
 vergeben.
 Wenn man dass Aussehen (Physis) beschreiben will, soll man ein Tag für
 eben dieses vergeben.
 Wenn man eine Nutzung beschreiben will soll man ein tag für die Nutzung
 vergeben.
 
 Aber dieses ein Haupt-Tag für alle gemeinsamen Ausprägungen ist in
 meinen Augen nicht zielführend - weder beim Mappen noch beim Auswerten.
 
 Gruß
 Georg
 
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


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

Re: [Talk-de] Frage bez. Kacheln

2011-09-07 Thread Peter Wendorff

Wenn Du ein aktuelles osmosis und aktuelle Daten hast (nach 0.6 API), 
dann sollte


osmosis --read-xml 0001.osm --sort outPipe.0=1sorted
--read-xml 0002.osm --sort outPipe.0=2sorted --merge
conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted
--write-xml merged.osm

vermutlich funktionieren: migrate fliegt raus, read-xml-0.5 wird durch 
read-xml ersetzt; ansonsten ist der Befehl identisch.


Gruß
Peter

Am 07.09.2011 10:54, schrieb Lars Schimmer:

On 2011-09-07 10:49, Lars Schimmer wrote:

On 2011-09-06 19:04, ant wrote:

On 06.09.2011 18:27, ant wrote:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm


Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp
kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes
überschrieben werden:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted
--write-xml merged.osm


Hm, das Osmosis 0.39 meckert da aber fleissig:
task type read-xml-0.5 not existant
task type --migrate not existant...


Ha, Osmosis ist zu aktuell, der kann kein migrate mehr und ich hab da 
noch alte 0.5 Daten im Auszug, also mal suchen...



Grüße
ant


MfG,
Lars Schimmer



MfG,
Lars Schimmer



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

Re: [Talk-de] Frage bez. Kacheln


On 2011-09-07 10:59, Igor Podolskiy wrote:

Hallo Lars,


Ha, Osmosis ist zu aktuell, der kann kein migrate mehr und ich hab da
noch alte 0.5 Daten im Auszug, also mal suchen...


Du könntest Osmosis 0.35 nehmen (die letzte Version, die API 0.5 konnte), damit 
die Migration machen und dann mit 0.39 weiterarbeiten.


So hab ich versucht, dann schmeisst mir Osmosis aber wieder Fehler im 
kernel:
java.lang.LinkageError: loader (instance of 
org/codehaus/plexus/classworlds/realm/ClassRealm): attempted  duplicate 
class definition for name: 
org/apache/xerces/jaxp/datatype/DatatypeFactoryImpl



Ich hänge etwas. Ich hab schön die Tiles von Computerteddy geholt, och 
hab dafür die SRTM tiles geholt und in OSM Format.


Und die Tiles von Computerteddy/ oder die SRTM Teiles sind kein 0.6 API:
SEVERE: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 20 
does not have a version attribute as OSM 0.6 are required to have.  Is 
this a 0.5 file?
Sep 7, 2011 11:28:24 AM 
org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager 
waitForCompletion

SEVERE: Thread for task 3-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 150542520 
does not have a version attribute as OSM 0.6 are required to have.  Is 
this a 0.5 file?



Jetzt muß ich doch nur noch diese beiden joinen und dann ein 
gmapsupp.img daraus bauen.




Ciao
Igor



MfG,
Lars Schimmer
--
-
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

Am 7. September 2011 09:03 schrieb Georg Feddern o...@bavarianmallet.de:
 Albrecht Will schrieb:
 Trotzdem sollten die planmäßigen Windschutzstreifen nach zahlreichen
 Flurneuordnungen im Zuge der Ausbildung landw. Großproduktion (LPG, Schläge
 über 300 ha und mehr ) in der damaligen DDR ein besonderes tag bekommen.
 hmm, wodurch unterscheiden sie sich denn von sonstigen (kleineren)
 Windschutzstreifen (Knicks) wie z. B. hier in der Probstei?
 Sowohl die Funktion als auch das Material ist doch das gleiche - einzig die
 Größe ist unterschiedlich.
 Sollen die planmäßigen Landwirtschaftsflächen im Zuge der Ausbildung landw.
 Großproduktion (LPG, Schläge über 300 ha und mehr ) in der damaligen DDR
 dann auch ein besonderes tag bekommen?.


könnten sie. Wenn Leute das gerne als besondere Eigenschaft taggen
wollen. Nur würde ich dafür eher einen neuen zusätzlichen Key erfinden
(nicht wörtlich nehmen, so was mit der Bedeutung
zusammengelegt_wegen_Umstellung_auf_sozialistische_Planwirtschaft=ja/1952(Jahr
der Zusammenlegung)/... ) und nicht landuse oder natural um einen
Spezialwert erweitern.


 Es ist doch einzig eine Frage der Größe - und somit je nach
 Auflösungsvermögen (hier insbesondere in der Breite) nur die Frage ob eben
 Linie oder eben Fläche.


nein, es ist auch ein geschichtlicher Fakt, der sich dort in der
Landschaft manifestiert (die Zusammenlegung der Flächen)


 Wenn man eine Funktion beschreiben will, soll man ein tag für Funktion
 vergeben.


+1

 Wenn man dass Aussehen (Physis) beschreiben will, soll man ein Tag für eben
 dieses vergeben.


+1


 Wenn man eine Nutzung beschreiben will soll man ein tag für die Nutzung
 vergeben.

+1


 Aber dieses ein Haupt-Tag für alle gemeinsamen Ausprägungen ist in meinen
 Augen nicht zielführend - weder beim Mappen noch beim Auswerten.

+1

Gruß Martin

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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

Am 7. September 2011 10:43 schrieb Albrecht Will albrecht.w...@online.de:
 Details in der Natur haben grundsätzlich das Problem, daß sie sich in
 überschaubarer Zeit ändern.


Details in der Stadt erst Recht. Deshalb sind wir ja permanent am
Überarbeiten. Solange wir von deutscher Kulturlandschaft sprechen habe
ich keine Bedenken, dass wir auch Details wie die hier besprochenen
einigermaßen aktuell halten können. So schnell werden z.T.
jahrhundertealte Hecken, die sich auf Eigentumsgrenzen befinden, nicht
abrasiert, und wenn das doch mal vorkommen sollte dann führen wir das
in OSM nach.


 Hier noch zur Rückfrage zu Pionierpflanzen/Ruderalflora, weil es zum Thema
 Detailtiefe paßt. Wenn das Gebiet lange genug in Ruhe gelassen wird, siehst Du
 plötzlich Wald. Ich werden meine 20 Jahre alten scrub-Flächen wohl sukzessive
 dahin umwandeln müssen.


ja, wenn es sich ändert/transformiert, passen wir auch die Daten an.
Wenn man in 5 oder 10 Jahren in OSM eine Fläche findet, für die als
Vegetation Ruderalflora angegeben ist, und die seither nicht geändert
wurde, dann kann man sich vermutlich auch denken, dass es dort
mittlerweile eine Veränderung gegeben hat, und man kann sich evtl.
(falls dort keine Eingriffe stattgefunden haben) sogar ableiten, wie
es mittlerweile dort aussehen wird.


 (Da muß ich wohl noch ein Problem anstoßen. Unser zumeist forstlich genutzter
 Wald ist durch Gestelle/Wege in Jagen unterteilt. Die Eigenschaften der Jagen
 ändern sich - Alter, Baumart, Dichte  Um das darzustellen müßte die
 bisherige Darstellung - ein großes Waldgebiet - aus einem Mosaik
 zusammengesetzt werden, oder?


ja. Meine Vorstellung ist, dass wir einerseits geografische Objekte
wie einen Wald haben (natural), der relativ große Gebiete beschreibt
(ggf. hierarchisch gegliedert, theoretisch bis hinunter zum einzelnen
benamten/nummerierten Waldstück) und andererseits kleinere Teile, die
jeweils Gebiete mit gleicher Charakteristik beschreiben (Baumbestand,
Dichte, Waldart, etc.) mit einer Serie von tags m.E. aus dem Bereich
landcover. Die vor ein paar Jahren eingeführte Trennung von Naturwald
als natural=wood und gepflegter Wald als landuse ist wenig zielführend
und erkennbar aus dem Versuch entstanden, nachträglich dem
Tagging-Chaos eine Bedeutung zuzuweisen.

Es gibt zum Thema landcover derzeit auch eine Diskussion auf
[tagging], wo professionelle landcover-Schemata (eins von der
Welternährungsorganisation FAO und eins von amerikanischen Behörden)
angesehen werden und überlegt wird, ob man da was für OSM lernen kann.
http://lists.openstreetmap.org/pipermail/tagging/2011-September/008485.html

Was sich dort bisher herauszukristallieren scheint ist, dass man
sinnvollerweise verschiedene elementare Eigenschaften getrennt
erfasst, um die genaue Charakteristik dann aus der Kombination
herauslesen zu können. Bisher kann man unsere Wälder ja nur sehr grob
in Nadel-/Laub- und gemischte Wälder unterteilen, mit einer
behaupteten Zusatzeigenschaft naturbelassen oder nicht (ich schreibe
behauptet weil es zumindest in meiner Gegend zufällig scheint, welchen
Tag der Mapper wählt).

Ein Beispiel: wir könnten ein Zusatzattribut haben:
Vegetationsdichte=dicht/dünn und damit dichten Wald von lückenhaft
stehenden Bäumen (woodland) genauso unterscheiden wie Heide von
dichtem Gestrüpp.


 Und wer behält das im Auge? Gibt es in späteren
 Jahren Mapper, die Fortschreibungen als Aufgabe sehen und annehmen?)


wenn alles gut geht, ja. Falls nicht, dann spielt es auch keine Rolle.
Wobei man sich bei der Wahl der tags natürlich auch selbst ins Knie
schießen kann, z.B. das Alter der Bäume. Da kann man entweder einen
tag wählen, der das ungefähre Pflanzjahr beschreibt, oder einen, der
ungefähr das Alter in Jahren angibt. Welcher besser funktioniert kann
sich jeder selbst überlegen.


 Laß uns aber doch einfach die eingeführte Symbolik der Geografen im Auge
 behalten. Wenn die Allee durch eine einreihige Perlenschnur von Kullern
 parallel zur Straße dargestellt wird, dann ist es doch nicht weit entfernt,
 noch eine oder zwei Reihen von kleineren Kullern daneben zu führen und sie für
 eine linienförmige Gehölzfläche zu nutzen.


das sind Darstellungsmöglichkeiten der Daten, und man kann das alles
machen, sofern man aus den Daten herauslesen kann, um was es sich
handelt.


 Während in der Magdeburger Börde von den alten Gehölzstreifen oder auch ein-
 und zweiseitigen (Obst) Bepflanzungen kaum noch was übrig ist, haben meine
 Vormapper in meiner Gegend genau die Grünstreifen (die es hier noch reichlich
 gibt und die Landschaft zum Glück prägen) übrig gelassen. Was mache ich mit
 den weißen Streifen? In der Mitte ist ein Bach.


den Bach würde ich als erstes mappen. Weitere Details könnten die
Böschung sein (je nach Tiefe mehr oder weniger interessant). Für
Ufergrün kann man evtl. einen neuen Tag bzw. Wert erfinden.


 Eine Lösungsvariante wäre für
 mich, landuse mit dem Gewässer zu koppeln und die oben erwähnten Kullern
 parallel zum Gewässer

Re: [Talk-de] Srtm2OSM unter linux

2011-09-07 Thread Fabian Schmidt



Am 06.09.11 schrieb Lars Schimmer:

Ok, ich möchte eigentlich nur eine Garmin Karte erstellen. Und das von einer 
Region von 5°x5° hier im Süd-Osten.


Für meine Urlaubskarte hab ich mkgmap die Daten von 
http://geoweb.hft-stuttgart.de/SRTM/srtm_as_osm/ gegeben.



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

Re: [Talk-de] Begleitgrün an Wegen und Bächen

2011-09-07 Thread Andreas Dommaschk


Am 07.09.2011 10:18, schrieb Falk Zscheile:

Euer Heckenstreit verlangt förmlich nach einem sub-Tag. Ich denke im
wesentlichen Einig ist sich die Runde, dass es verschiedene Formen von
Hecken gibt. Von der geschnittenen im Vorgarten, über solche zum
Schutz von Feldern (Knicks in S-H, Buchenhecken in der Eifel) bis hin
zu solchen, die erst noch eine richtige werden soll Benjeshecke.

Macht ein barrier=hedge dann weiß erst einmal jeder was gemeint ist
(auch außerhalb von Deutschland). Jeder der mehr in der Landschaft
sieht als das ist eine Hecke kann dann ohne weiteres ein sub-Tag
ergänzen und dort kann sich jeder austoben und seine Knicks,
Benjeshecken, LPG-Hecken oder was auch immer verwursten. Auch den
Leuten, welche die Daten auswerten macht man es so einfacher, als wenn
die erst einmal recherchieren müssen ob eine Hecke am Feld in S-H
anders heißt als in M-V oder in der Eifel. Und im Falle eines
Kleinkrieges über die richtige Einordnung einer Hecke bleibt zumindest
das übergeordnete Tag gleich und der Datenbestand brauchbar.

Gruß, Falk

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

+1

Gruß, Andreas

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

Re: [Talk-de] Frage bez. Kacheln

2011-09-07 Thread ant

oh ja stimmt, habe osmosis 0.34 aus dem Debian-Paket benutzt, ohne es zu 
merken...


Grüße
ant

On 07.09.2011 10:49, Lars Schimmer wrote:

On 2011-09-06 19:04, ant wrote:

On 06.09.2011 18:27, ant wrote:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm


Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp
kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes
überschrieben werden:

osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted
--read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge
conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted
--write-xml merged.osm


Hm, das Osmosis 0.39 meckert da aber fleissig:
task type read-xml-0.5 not existant
task type --migrate not existant...



Grüße
ant


MfG,
Lars Schimmer


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

Re: [Talk-de] Frage bez. Kacheln

2011-09-07 Thread ant


Hallo,

On 07.09.2011 11:29, Lars Schimmer wrote:

Und die Tiles von Computerteddy/ oder die SRTM Teiles sind kein 0.6 API:
SEVERE: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 20
does not have a version attribute as OSM 0.6 are required to have. Is
this a 0.5 file?
Sep 7, 2011 11:28:24 AM
org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager
waitForCompletion
SEVERE: Thread for task 3-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 150542520
does not have a version attribute as OSM 0.6 are required to have. Is
this a 0.5 file?


er meckert, weil einige Nodes kein version-Attribut haben. Das 
Migirieren von 0.5 nach 0.6 ist nur eine Lösung. Alternativ könntest du 
auch einfach mit dem Texteditor deiner Wahl ein version=1 überall dort 
einfügen, wo es fehlt, und die Datei damit API-0.6-kompatibel machen... 
dann sollte osmosis auch still sein.


Grüße
ant




Jetzt muß ich doch nur noch diese beiden joinen und dann ein
gmapsupp.img daraus bauen.



Ciao
Igor



MfG,
Lars Schimmer


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

[Talk-de] Bauen einer Karte...


Moin!

So, diverse kleinere Probleme gelöst und viele viele weitere wieder 
aufgetan.

Meine Vorgehensweise:
0. Schauen, welche tiles ich brauche (Nummern)

1. Tiles von Computerteddy holen

2. für diese Tiles SRTM Daten holen und ins OSM Format wandeln (SRTm2OSM)
= 3GB Tiles von Computerteddy, 9GB SRTM Tiles RAW

3. mit mkgmap.jar jeweils ein gmapsupp für die Tiles und eine für SRTM 
erzeugen. Dabei wirft es aber bei den 25 Computerteddy Tiles manchmal 
einen Error (wenn man einfach tiles_6* schreibt, schreibt man die 25 
einzelnen tiles hin, gibt es keinen Error. War von wegen: SRT Datei 
konnte nicht geschrieben werden, schon voirhanden)



4. mit lgmt042a.zip beide gmapsupp.img zu einem zusammenfügen
das wirft dabei folgende Warnings mehrmals:
== Warning: repeated map ID number.


5. jetzt warten bis ich es auf meinem garmin testen kann

Interessant, da aus den ganzen RAW Daten eine 180MB Datei rauskommt. Da 
kann was bei komisch sein, muß aber ned.


Ist der Ansatz grundsätzlich OK?
Die meisten, die ich gelesen habe, schneiden einen Bereich aus der 
ganzen Karte aus und holen die Daten dann rüber in eine Datei, splitten 
die dann auf und werkeln auf den dann weiter.



MfG,
Lars Schimmer
--
-
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Bauen einer Karte...

2011-09-07 Thread Torsten Leistikow

Moin,

Lars Schimmer schrieb am 07.09.2011 15:49:
 3. mit mkgmap.jar jeweils ein gmapsupp für die Tiles und eine für SRTM
 erzeugen. Dabei wirft es aber bei den 25 Computerteddy Tiles manchmal
 einen Error (wenn man einfach tiles_6* schreibt, schreibt man die 25
 einzelnen tiles hin, gibt es keinen Error. War von wegen: SRT Datei
 konnte nicht geschrieben werden, schon voirhanden)
 
 
 4. mit lgmt042a.zip beide gmapsupp.img zu einem zusammenfügen
 das wirft dabei folgende Warnings mehrmals:
 == Warning: repeated map ID number.

Es spricht m.E. nichts dagegen, gleich mit mkgmapn eine gemeinsame gmapsupp.img
Datei aus den OSM und SRTM Daten zu erzeugen. Das kann man in einem Schritt
machen, mkgmap kann aber auch nachtraeglich img-Dateien zu einer gmapsupp.img
zusammenpacken.

 Die meisten, die ich gelesen habe, schneiden einen Bereich aus der
 ganzen Karte aus und holen die Daten dann rüber in eine Datei, splitten
 die dann auf und werkeln auf den dann weiter.

Das Routing von einer Kartenkachel zur naechsten ist nicht ganz unproblematisch.
Frueher ging das mit den Kacheln von Comupterteddy gar nicht, ob sich das
inzwischen geaendert hat, weiss ich nicht. Wenn man sich die Kacheln selber
schneidet, hat man auf alle Faelle den Vorteil, dass man die Kacheln guenstiger
geschnitten sind, so dass man mit weniger Kacheln auskommt und deshalb auch nur
ueber weniger Kachelgrenzen routen muss.

Gruss
Torsten

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

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

2011-09-07 Thread Christian Müller


Hi,


Am 07.09.2011 02:38, schrieb Martin Koppenhoefer:
hier kann ich nicht mehr folgen. Es ging ja nie um Grundstücksflächen 
sondern zum einen darum, welche wo die landuse-Grenzen gezeichnet 
werden sollen und zum anderen dann um Wohngebiete.


Insbesondere /Dir/ ging es tatsächlich um Grundstücksflächen.  Deiner 
Meinung nach sollte landuse=residential für Gruppen aneinanderhängender 
Grundstücksflächen herhalten, die für den Zweck des Wohnens benutzt 
würden, womit /Du/ landuse=residential-Grenzen _eindeutig_ entlang 
Grundstücks/Flurgrenzen zu zeichnen hättest.



M.E. ist die Verwendung von landuse=residential so wie sie ist, weil 
der Renderer dann wie in vielen anderen Karten auch in 
Übersichts-Zoombereichen einen durchgehenden grauen Hintergrund unter 
die Siedlung legt, und das ganz gut aussieht. Zu viel Fragmentierung 
würde nur unruhig wirken und stören. Eigentlich also klassisches 
taggen für die Renderer. Ein Viertel der cities sind schon als places 
erfasst, auch wenn das in den OSM-renderern nicht dargestellt wird. 
Würde mapnik in Zoom 9-12 anstatt der Stadt-landuses place-Flächen 
rendern, dann hätten wir sehr schnell auch die übrigen 3/4 erfasst ;-) 


Das Rendering war nie Bestandteil unserer Diskussion, warum fängst Du 
jetzt damit an?  Weshalb es durchaus Sinn macht, Flächen an Wege zu 
taggen und weshalb nicht, haben wir m.E. ausreichend erörtert - ich 
werde meine (und deine) Ausarbeitungen dazu nicht wiederholen.  Das 
MapperInnen Flächen an Wege /rein des Renderings wegen/ pappen, ist 
reine Spekulation.




Wir brauchen eine bessere Differenzierung des Wohngebietes (welchem
landuse=residential bisher hauptsächlich zurechenbar sein dürfte) auf
der einen und der Wohngrundstücksfläche (welche von der Begrifflichkeit
evtl. dem Tag landuse=residential sogar näher steht), auf der anderen
Seite.

Aus der Diskussion ist ein Proposal für Untereinheiten von Orten
entstanden, womit man Wohngebiete als das deklarieren kann, was sie
sind: besiedelte Gebiete mit Namen, Untereinheiten einer größeren
Siedlung, also place in OSM:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/place%3Dneighbourhood


Das ist nett, aber noch keine vollständige Lösung.  Meines Erachtens 
sollten die place-Tags hauptsächlich einen POI-Charakter behalten  
(village, locality, hamlet, etc.), weil die ihnen zuzurechnende Fläche 
bereits durch boundary=administrative gegeben ist.  Das wird zudem als 
/best practice/ im Wiki empfohlen.


Demnach kann dein Vorschlag aus Konsistenzgründen nur sein:

  - erfasse einen node mit place=neighbourhood und name=* im Zentrum 
der Nachbarschaft

  - erfasse die Grenze als boundary=administrative mit entspr. admin_level
  - füge den node als admin_centre in die boundary-Relation

Ich kann dann, wie ich bereits im Beispiel für eine gesamte Stadt 
schrieb, die neighbourhood-boundary als Multipolygon verwenden, um mir 
alle enthaltenen Daten, also auch die Flächennutzungen, auszuschneiden.


Damit hättest Du erfolgreich die Flächen/nutzung/ von der sprachlichen 
Implikation gelöst, die durch die Begriffswahl des Gebietes entsteht, 
innerhalb welchem die Fläche liegt.  D.h. eine neighbourhood kann dann 
mehrere Flächen mit verschiedener Flächennutzung beinhalten, also der 
Begriff Wohngbiet würde dann nicht mehr _alle_ seine enthaltenen 
Flächen an landuse=residential binden.


(A)- /Das/ ist, so wie ich die community verstanden habe, weder 
gewünscht noch notwendig
- denn die Auffassung ist:  Ein Wohngebiet (Du nutzt 
Nachbarschaft) impliziert landuse=residential.
- dabei spielt es keine Rolle, ob noch andere Flächennutzungen 
im Spiel sind (Spielplatz, Bäcker, Obstladen, etc.)


(B)- Selbst wenn wir diese saubere Trennung von /admin. 
Gebietsdefinition/ und /Flächennutzung/ hätten:
- die Flächennutzung würde dann _nicht_ durch admin. Gebiet 
vorgegeben/vererbt
- Wohngebiet impliziert dann _nicht_, dass jede 
enthaltene Fläche zum Wohnen verwendet wird
- wo gehören die Grenzen der Flächennutzung 
(landuse=residential) dann deiner Meinung nach hin?

- bist Du dann wieder an der Grundstücksgrenze?
- sozusagen als kleinstes admin. Gebiet, welchem man 
dann eine konkrete Flächennutzung (landuse) zubilligen darf?
- die Grenze der größten Fläche, die man dann mit 
(landuse=residential) taggen dürfte,
verliefe an der äußeren Grenze zusammenhängender 
Grundstücke der gleichen Nutzungsart



Auf die Gefahr hin, dass ich mich wiederhole:  (B) ist nicht unlogisch, 
aber es steht in krassem Gegensatz zu (A), der momentan etablierten 
Nutzung von landuse=residential.  Daher weitherhin mein Vorschlag:


- parcel data als Grenze eintragen
- von mir aus auch neighbourhoods als Grenze eintragen

- die Flächennutzung innerhalb dieser admin. Gebiete aber durch den 
Schnitt mit den restlichen Daten ermitteln




Landuses, insbes. landuse=residential, wären dann weiterhin als größte

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

Am 7. September 2011 17:12 schrieb Christian Müller cmu...@gmx.de:
Am 07.09.2011 02:38, schrieb Martin Koppenhoefer:

hier kann ich nicht mehr folgen. Es ging ja nie um Grundstücksflächen
sondern zum einen darum, welche wo die landuse-Grenzen gezeichnet werden
sollen und zum anderen dann um Wohngebiete.

Insbesondere /Dir/ ging es tatsächlich um Grundstücksflächen.

nein, es ging mir um landuse.

Deiner
Meinung nach sollte landuse=residential für Gruppen aneinanderhängender
Grundstücksflächen herhalten, die für den Zweck des Wohnens benutzt würden,
womit /Du/ landuse=residential-Grenzen _eindeutig_ entlang
Grundstücks/Flurgrenzen zu zeichnen hättest.

ja, wobei größere Flächen aneinanderhängender Grundstücksflächen (also
zusammenhängender, gleicher landuse) eben nicht dasselbe sind wie
Grundstücksflächen. Es geht mir nicht um die Grundstücke selbst
sondern darum, dass landuse=residential auf Grundstücken stattfindet.

M.E. ist die Verwendung von landuse=residential so wie sie ist, weil der
Renderer dann wie in vielen anderen Karten auch in Übersichts-Zoombereichen
einen durchgehenden grauen Hintergrund unter die Siedlung legt, und das ganz
gut aussieht. Zu viel Fragmentierung würde nur unruhig wirken und stören.
Eigentlich also klassisches taggen für die Renderer. ...

Das Rendering war nie Bestandteil unserer Diskussion, warum fängst Du jetzt
damit an?

das schreibe ich doch oben: weil es hier m.E. ein Fall von Taggen für
den Renderer ist.

Weshalb es durchaus Sinn macht, Flächen an Wege zu taggen und
weshalb nicht, haben wir m.E. ausreichend erörtert - ich werde meine (und
deine) Ausarbeitungen dazu nicht wiederholen. Das MapperInnen Flächen an
Wege /rein des Renderings wegen/ pappen, ist reine Spekulation.

Das zielte mehr darauf ab, dass man einzelne Grundstücke (Fred
bestätigte das gar für ganze Fabriken) unterschlagen soll.

Wir brauchen eine bessere Differenzierung des Wohngebietes (welchem
landuse=residential bisher hauptsächlich zurechenbar sein dürfte) auf
der einen und der Wohngrundstücksfläche (welche von der Begrifflichkeit
evtl. dem Tag landuse=residential sogar näher steht), auf der anderen
Seite.

m.E. brauchen wir Wohngebiete überhaupt, damit wir z.B. danach
suchen können. Ich will mich ungern darauf verlassen, dass jedes
Objekt das sowohl landuse=residential als auch einen Namen hat, evtl.
auch ein Wohngebiet sein könnte. Auch würde ich gerne abweichende
Nutzungen in Wohngebieten mappen.

Das ist nett, aber noch keine vollständige Lösung. Meines Erachtens sollten
die place-Tags hauptsächlich einen POI-Charakter behalten (village,
locality, hamlet, etc.), weil die ihnen zuzurechnende Fläche bereits durch
boundary=administrative gegeben ist. Das wird zudem als /best practice/ im
Wiki empfohlen.

Typischer Fall von Wikifiddling: kannst Du bitte Deine Änderung von
heute wieder rückgängig machen?
http://wiki.openstreetmap.org/w/index.php?title=Key%3Aplaceaction=historysubmitdiff=681038oldid=674877
In dem o.g. Absatz stehen mehrere Dinge, die so nicht stimmen.
locality steht für Orte die keine Siedlungen sind (also ziemlich
sicher keine eigene administrative Grenze haben) und auch viele der
übrigen places sind nicht das admin_centre einer zugeordneten
Verwaltungsgrenze. Die best practice im Wiki kann sich also nur auf
Spezialfälle beziehen und funktioniert nicht als allgemeiner Vorschlag
für Siedlungen sondern nur für Verwaltungszentren. Wäre m.E. daher
besser auf der Wiki-Seite zu admin aufgehoben als bei Place.

Übrigens: um anzugeben, welcher Ort sich innerhalb welcher
Verwaltungsgrenze befindet, braucht man keine Relation: das ist ja
gerade die Eigenschaft von Grenzen dass sie umschließen.

Es gibt einen Unterschied zwischen administrierter Fläche
(boundary=administrative) und Siedlungsfläche (place-polygon), daher
braucht man auch beide. Als best_practice würde ich vorschlagen, für
places eine Relation zu machen und den place-node mit der Rolle
settlement_centre dort mit der Place-Fläche zu verknüpfen.

Einfacher zu warten ist m.E. der Tag am einzelnen Grundstück.
Redundanz, wir kommen.

redundant wäre das nur, wenn man zusätzlich noch mal eine große
landuse-Fläche drum rum bauen würde. Redundante Geometrie würde im
Gegenteil dann entstehen, wenn man _nicht_ die Grundstücksflächen
(Hypothese aus Deiner Mail, man hätte sie) dafür verwenden würde
sondern nochmal extra ein Polygon drum rum zieht.

Eher andersrum: Ich würde das Tag maximal an einzelne Grundstücke vergeben,
die eine Ausnahme der Regel darstellen. Z.B. wenn es eine mall innerhalb
eines Wohngebietes gibt.

+1, schrieb ich ja bereits und ist genau das, worum es hier geht. Wir
verstehen uns langsam.

ich will nichts ummünzen. Mir ging es darum, die Daten möglichst logisch zu
strukturieren. Landuse als tag für die Nutzung, (wie übrigens seit jeher im
Wiki beschrieben), ändert sich durch die Einführung von Wohngebieten im
place-tag nicht.

Das ist blauäugig. Durch das

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

Am 7. September 2011 20:09 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Jedes Grundstück hat eine (zulässige und reale) Nutzung. Wenn
 für ein bestimmtes Grundstück nichts zugewiesen ist, dann gilt das
 Einfügungsgebot. Wenn aber eine Nutzung zugewiesen ist, dann ist diese
 entscheidend und die Umgebung ist egal.

Kleine Präzisierung/Richtigstellung:

Es gibt in der Tat eine tatsächliche Nutzung, und eine solche wird
nachrichtlich im Liegenschaftkataster festgehalten (für uns
irrelevant, weil uns die echte Nutzung interessiert und nicht die, die
als echte Nutzung im Kataster steht). Die Zuweisung einer Nutzung zu
einem Grundstück bezog sich auf die Planung (Bebaungsplan), also
welche Bauvorhaben auf einem Grundstück zulässig sind. Wenn es keinen
Bebauungsplan gibt, dann gilt wie dargestellt das Einfügungsgebot,
aber natürlich nur für neue Bauvorhaben. Was bereits dort vorhanden
ist genießt in der Regel Bestandsschutz. In der Realität kann es
soweit ich weiss aber auch vorkommen, dass im Kataster für ein
Flurstück (also Grundstück bzw. Teil davon) mehrere Nutzungen räumlich
abgegrenzt werden. Rechtlich gesehen ist also das Flurstück auf die
Nutzung bezogen nicht grundsätzlich die kleinste Einheit.


 so lapidar steht das im Wiki. Wie groß dieses Gebiet sein soll, steht
 da aber nicht. Logisch aus meiner Sicht wäre das einzelne Grundstück
 als atomare Größe für Landnutzung (weil es der gesetzlichen Realität
 entspricht).


der vg. Absatz ist demzufolge auch nicht ganz richtig. Um
abzuschätzen, wie groß die Einheiten, die man mit landuse minimal
ausdrücken sollte, ungefähr sein sollten, finde ich den
Grundstücksmaßstab trotzdem nicht falsch. In Ausnahmen kann es sein,
dass man davon abweichen will.

Gruß Martin

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

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

2011-09-07 Thread Frederik Ramm


Hallo,

On 09/07/2011 08:09 PM, Martin Koppenhoefer wrote:

das schreibe ich doch oben: weil es hier m.E. ein Fall von Taggen für
den Renderer ist.


Dass landuse=residential auf Grundstuecken stattfindet ist eine 
Einzelmeinung von Dir, die schlicht und einfach nicht dem entspricht, 
was in OSM bislang gemacht wurde.


landuse=residential ist fuer Flaechen mit vornehmlich Wohnbebauung, 
d.h. es kann durchaus auch nicht-Wohnbebauung (Kiosk, Strasse, Park) 
drinliegen.


Das war schon immer so und ich bin von Deinen Argumenten fuer eine 
Aenderung - die im wesentlichen auf m.E. hinauslaufen - nicht ueberzeugt.



Das zielte mehr darauf ab, dass man einzelne Grundstücke (Fred
bestätigte das gar für ganze Fabriken) unterschlagen soll.


Nicht unterschlagen. Ein Gebiet mit vornehmlich Wohnbebauung aendert 
nicht ploetzlich seinen Charakter, wenn dazwischen mal was ist, was fuer 
sich genommen kein landuse=residential rechtfertigen wuerde.



m.E. brauchen wir Wohngebiete überhaupt, damit wir z.B. danach
suchen können. Ich will mich ungern darauf verlassen, dass jedes
Objekt das sowohl landuse=residential als auch einen Namen hat, evtl.
auch ein Wohngebiet sein könnte. Auch würde ich gerne abweichende
Nutzungen in Wohngebieten mappen.


Dann schneide Du doch von mir aus ein landuse=retail in das Wohngebiet 
fuer den Tante-Emma-Laden (und zerbrich Du Dir den Kopf darueber, was Du 
machst, wenn die Tante Emma obendrueber ihre Wohnung hat). Bloss bitte 
versuche nicht, uns anderen das aufzudruecken.



Das ist nett, aber noch keine vollständige Lösung.  Meines Erachtens sollten
die place-Tags hauptsächlich einen POI-Charakter behalten  (village,
locality, hamlet, etc.), weil die ihnen zuzurechnende Fläche bereits durch
boundary=administrative gegeben ist.  Das wird zudem als /best practice/ im
Wiki empfohlen.


Dem stimme ich zu. place=... als Flaechenbezeichnung hat keine 
Tradition, und wir sollten ganz gewiss nicht jetzt hopplahopp eine ein 
place=wohngebiet als Flaeche einfuegen, nur damit Martin dann behaupten 
kann, dass landuse=residential doch bitte fuer einzelne Grundstuecke 
verwendet werden solle.


Ich hab auf diese Diskussion jetzt echt keine Lust mehr. Wie gesagt, 
Martin, wenn Du es gern selbst anders machen willst, mach es anders. 
Aber bitte hoer auf, jedem zu erzaehlen, es waere irgenwie falsch, 
wenn man ein landuse=residential um ein Wohngebiet mit ein paar Strassen 
und ein paar Laeden zieht, denn genau das machen fast alle ausser Dir.


Ich musste - so viel zum Thema Wikifiddling - aus dem Wiki schon die 
dreiste (nomen est omen!) Behauptung von Dir entfernen, dass 
landuse=residential missbraucht werde, um Wohngebiete zu mappen. Das 
Tag ist dafuer geeignet und wird dafuer eingesetzt. Dass es sich um 
einen Missbrauch handelt, das findet nur in Deinem Kopf statt.


Seit es die deutsche landuse=residential-Seite im Wiki gibt (Juni 2010), 
steht da: Ein Gebiet, das überwiegend mit Wohnhäusern und 
Wohn-Geschäftshäusern aller Art bebaut ist; auch für Wohn- und 
Mischgebiete vorgesehene Baugebiete. - das Wiki ist mir zwar alles 
andere als heilig, aber mit dieser Definition stimme ich ueberein, und 
ich denke, das tun auch die meisten anderen Mapper.


Dein place=neighbourhood-Proposal hat fuer mich den Beigeschmack, als 
wollest Du damit diese Nutzung von landuse=residential aufweichen. Du 
kannst Dir meines erbitterten Widerstandes gewiss sein, wenn ich Dich 
dabei erwische, wie Du Leuten erzaehlst, es waere falsch, 
landuse=residential um ein ganzes Wohngebiet zu zeichnen, denn 
neuerdings sei dafuer ja das neue Tag place=neighbourhood vorgesehen. 
Der einzige, der das vorsieht, bist naemlich Du.


Bye
Frederik

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

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

Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued

Am 7. September 2011 21:06 schrieb Frederik Ramm frede...@remote.org:
 On 09/07/2011 08:09 PM, Martin Koppenhoefer wrote:
 das schreibe ich doch oben: weil es hier m.E. ein Fall von Taggen für
 den Renderer ist.
 Dass landuse=residential auf Grundstuecken stattfindet ist eine
 Einzelmeinung von Dir, die schlicht und einfach nicht dem entspricht, was in
 OSM bislang gemacht wurde.


nicht nur residential, auch industrial, commercial, retail, farmyard
und cemetary.


 landuse=residential ist fuer Flaechen mit vornehmlich Wohnbebauung, d.h.
 es kann durchaus auch nicht-Wohnbebauung (Kiosk, Strasse, Park) drinliegen.
 Das war schon immer so und ich bin von Deinen Argumenten fuer eine Aenderung
 - die im wesentlichen auf m.E. hinauslaufen - nicht ueberzeugt.


Einen Kiosk würde ich auch problemlos im landuse=residential lassen,
genauso wie den Friseur, den Bäcker oder die Eckkneipe. Ein reines
Bürohaus, in dem keine Wohnung ist, würde ich dagegen als commercial
taggen. Auch in der Wohnsiedlung.


 Das zielte mehr darauf ab, dass man einzelne Grundstücke (Fred
 bestätigte das gar für ganze Fabriken) unterschlagen soll.

 Nicht unterschlagen. Ein Gebiet mit vornehmlich Wohnbebauung aendert nicht
 ploetzlich seinen Charakter, wenn dazwischen mal was ist, was fuer sich
 genommen kein landuse=residential rechtfertigen wuerde.


Das hört sich moderat an, hatte ich neulich anders verstanden. Da gibt
es nämlich ziemlich krasse Sondersituationen, wo ein Wohngebiet
plötzlich seinen Charakter ändert durch eine einzelne Nutzung:
http://www.flickr.com/photos/mecklenburg/5586760278/
Solange es sich um mit dem Wohnen verträgliche Nutzungen handelt, ist
residential passend, Fabriken gehören da nicht dazu...


 Dann schneide Du doch von mir aus ein landuse=retail in das Wohngebiet fuer
 den Tante-Emma-Laden (und zerbrich Du Dir den Kopf darueber, was Du machst,
 wenn die Tante Emma obendrueber ihre Wohnung hat).


in dem Fall sehe ich 2 Möglichkeiten: man zeichnet wirklich ein retail
aber schneidet das eben nicht aus, oder man sieht das auch als
residential (m.E. ja) und begnügt sich für die Ladennutzung mit dem
shop-tag.

Das Wort Wohngebiet hat im deutschen Sprachgebrauch zwei
Bedeutungen: zum einen ist es eine Gegend, in der vorwiegend gewohnt
wird, (und wo Kindergarten, Läden, Einkaufszentrum, Straßen mit
dazugehören) ein Synonym wäre Wohnsiedlung und es hat zum anderen
auf die Baunutzung bezogen eine besondere Bedeutung, die in
Verordnungen geregelt und definiert ist. Das erste ist ein Gebiet, in
dem es nicht nur landuse=residential geben wird, das zweite hatte ich
immer als eben genau landuse=residential gesehen.


 Dem stimme ich zu. place=... als Flaechenbezeichnung hat keine Tradition,


seit wann hängst Du denn so an Traditionen? Places als Flächen ist
schon seit Jahren Thema, im Wiki dokumentiert, und z.B. bei cities hat
fast jede Vierte einen Umriss, Tendenz steigend:
http://taginfo.openstreetmap.org/tags/place=city#wiki . Und das obwohl
Mapnik diese Flächen komplett ignoriert (und sich im lowzoom Bereich
lieber auf parallele Daten von natural-earth verlässt).


 Ich hab auf diese Diskussion jetzt echt keine Lust mehr.


+1. mappt wie Ihr wollt, das habe ich auch schon mal vor ein paar
Tagen geschrieben, und mich irgendwie jetzt doch noch ein paarmal
hinreissen lassen.


 Seit es die deutsche landuse=residential-Seite im Wiki gibt (Juni 2010),
 steht da: Ein Gebiet, das überwiegend mit Wohnhäusern und
 Wohn-Geschäftshäusern aller Art bebaut ist; auch für Wohn- und Mischgebiete
 vorgesehene Baugebiete.


Wobei hier der Hinweis gestattet sei, dass Mischgebiet auch ein
Fachwort aus der BauNVO ist, und es noch andere Arten von gemischten
Gebieten gibt (Kerngebiete). Mischgebiet bedeutet Gebiet für Wohnen
und das Wohnen nicht wesentlich störende Gewerbenutzungen (und zwar
folgende: Gewerbe, Tankstellen, Schulen, Sport, Kultur, Kirche,
soziale Einr., Gartenbau und Diskos in der Nähe des Gewerbes).

Eigentlich seltsam, dass man auch vorgesehene Baugebiete, auf denen
de fakto also vermutlich Wiese ist, so taggen soll. Sonst heisst es ja
immer dass man das taggen soll, was man vor Ort vorfindet. Wenn z.B.
ein ehemaliges Fabrikareal als Wohngebiet vorgesehen ist, wie soll man
das dann taggen (brownfield oder residential)? Und wie ein Gebiet
welches als Mischgebiet vorgesehen ist (sprich: Planung), das aber
derzeit eine andere Nutzung hat? M.E. wäre es besser, für vorgesehene
Nutzungsarten (also was ein qualifizierter Bebauungsplan vorsieht)
einen anderen Schlüssel als landuse zu verwenden, und landuse für
die tatsächliche Nutzung vorzubehalten.


 Du kannst
 Dir meines erbitterten Widerstandes gewiss sein, wenn ich Dich dabei
 erwische, wie Du Leuten erzaehlst, es waere falsch, landuse=residential um
 ein ganzes Wohngebiet zu zeichnen, denn neuerdings sei dafuer ja das neue
 Tag place=neighbourhood vorgesehen. Der einzige, der das vorsieht, bist
 naemlich Du.


Es gab jedenfalls auf tagging soweit ich mich erinnere keinen

[osm-ve] Garmin se tambalea

2011-09-07 Thread J . Hernán Ramírez R .

http://200.74.194.10/php/ver_noticia.php?ID=8288
--
Salva un árbol. No imprimas este correo a menos que sea realmente necesario.

-
J. Hernán Ramírez R
Blog http://blog.hernanramirez.info - Linux User
#97.898http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=97898
 -
Twitter @HernanRamriez http://twitter.com/HernanRamirez
Mapas Libres OpenStreetmap Venezuela http://openstreetmap.org.ve
-
___
Talk-ve mailing list
Talk-ve@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ve

[Talk-it] problema JOSM

2011-09-07 Thread Bruno

Salve a tutti. Ho cominciato da poco a mappare dei sentieri, soprattutto x  MTB 
in prov. di Latina. Ora però alcuni dei sentieri che ho mappato (già da diversi 
giorni), li vedo solo su JOSM e non sulla mappa di openstreetmap. Ho 
sicuramente fatto qualche errore, ma quale? 



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

Re: [Talk-it] problema JOSM

2011-09-07 Thread sabas88

Sicuro di aver schiacciato il tasto di upload (la freccia verso l'alto) e
averlo completato? :)
In genere sul rendering di openstreetmap.org dopo cinque minuti massimo ci
sono già (zoomando al massimo).
Ciao,
Stefano

Il giorno 07 settembre 2011 16:19, Bruno bruno@libero.it ha scritto:

 **

 Salve a tutti. Ho cominciato da poco a mappare dei sentieri, soprattutto x
  MTB in prov. di Latina. Ora però alcuni dei sentieri che ho mappato (già da
 diversi giorni), li vedo solo su JOSM e non sulla mappa di openstreetmap. Ho
 sicuramente fatto qualche errore, ma quale?



 Bruno

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


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

Re: [Talk-it] problema JOSM