date:20110213

On Mon, Feb 14, 2011 at 10:36 AM, Oscar Orbe oskaro...@yahoo.com wrote:

 hello list,
 here is a ranking of the cities/towns in Spain which need the most OSM
 love.
 click 4 times on the last column to see them sorted:

 http://bit.ly/eUkBpX


Wow, what a lot of work. What made you decide to go down the subjective
assessment path, rather than just counting the number of OSM entities within
a given bounding box?

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

Re: [OSM-talk] magical road detector to play with

2011-02-13 Per discussione David Murn

On Sun, 2011-02-13 at 19:52 +0100, Chris Browet wrote:
 
 
 On Sun, Feb 13, 2011 at 19:25, Chris Browet c...@semperpax.com
 wrote:
 Busy implementing in Merkaartor
 
 A bug:
 you output osmchange while it is osmChange, with a capital
 C. see http://wiki.openstreetmap.org/wiki/OsmChange
 
 - Chris -
 
 And, AFAIK, bounds below create is not valid. 

A program that came out of Microsoft, trying to slightly modify a
defacto file format standard, say it isnt so.  Next will come .MSO, its
just like .OSM but with the subtle MicroSoft Openstreetmap changes to
the existing format.



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

Re: [OSM-talk] Spain needs OSM love

2011-02-13 Per discussione David Murn

On Mon, 2011-02-14 at 10:44 +1100, Steve Bennett wrote:
 On Mon, Feb 14, 2011 at 10:36 AM, Oscar Orbe oskaro...@yahoo.com
 wrote:
 hello list,
 here is a ranking of the cities/towns in Spain which need the
 most OSM love.
 click 4 times on the last column to see them sorted:
 
 
 http://bit.ly/eUkBpX
 
 
 
 
 Wow, what a lot of work. What made you decide to go down the
 subjective assessment path, rather than just counting the number of
 OSM entities within a given bounding box?

Was this done entirely by hand, or did you have some automated process
to help with this?  Id really like to look at doing something similar
for other areas.

David




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

[OSM-talk] 12nm territorial borders - useful or rubbish?


Hi,

   I've been thinking about the 12nm territorial borders on sea that we 
have in many places, notably in Europe. Many of them seem to have been 
auto-generated by simply placing a buffer around the coastline.


My first question is, do they really have legal significance? They 
certainly give the impression of high precision, hugging every 
protruding bit of coastline in a safe distance.


For example, if I am inside this triangle between Scotland and Ireland, 
will my legal status (concerning, say, fishing quotas, or whom I can 
marry on board of my vessel, or whatever funny things influcenced by 
international borders) be really any different from the status I had if 
I moved my vessel 2 miles in either direction?


 http://www.openstreetmap.org/?lat=55.065lon=-5.567zoom=10layers=M

Or are we, by using these auto-generated (and perhaps not 
human-reviewed?) borders, suggesting a precision that isn't there? Would 
the UK coastguard have a good laugh when I claim to be in international 
waters at that location?


My second question is, assuming that indeed there is significance to the 
12 nm boundary - should such auto-generated data be in OSM at all? If 
you're out on the sea, should whatever navigational aid you carry not 
compute by itself how far you are from the coast, rather than telling 
you whether you're to the left or to the right of a previously computed 
12nm line?


And my third question is, assuming that there are really good reasons 
for having these lines in OSM - who takes care of updating them once the 
coastline is modified by a mapper? I think it is a rather unique 
situation to have that kind of data-derived-from-other-OSM-data in OSM 
itself, and thus this has many of the same problems that an import would 
have (i.e. the source data has changed, what now).


I'm not saying we should delete them; but whenever I see them on the map 
I tend to shrug and say well, seems like someone was trying out his 
PostGIS skillz, and somehow I have the suspicion that the 12nm line as 
depicted on our maps may be little more than that's what computer geeks 
do if you tell them the border is 12 miles out


I'd like to hear from people who tell me that yes, these borders are 
really useful to have ;)


Bye
Frederik

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

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

Re: [OSM-talk] magical road detector to play with

2011-02-13 Per discussione John-Michael Wiley

Not sure that was helpful. 

Anyway, I updated the staging servers with a new build that hopefully addresses 
the issues. Give it a try and let me know if you any issue.
- modified osmchange to osmChange
- removed the bounds

http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/

Thanks,
J.M.


-Original Message-
From: David Murn [mailto:da...@incanberra.com.au] 
Sent: Sunday, February 13, 2011 4:42 PM
To: Chris Browet
Cc: John-Michael Wiley; talk@openstreetmap.org
Subject: Re: [OSM-talk] magical road detector to play with

On Sun, 2011-02-13 at 19:52 +0100, Chris Browet wrote:
 
 
 On Sun, Feb 13, 2011 at 19:25, Chris Browet c...@semperpax.com
 wrote:
 Busy implementing in Merkaartor
 
 A bug:
 you output osmchange while it is osmChange, with a capital
 C. see http://wiki.openstreetmap.org/wiki/OsmChange
 
 - Chris -
 
 And, AFAIK, bounds below create is not valid. 

A program that came out of Microsoft, trying to slightly modify a defacto file 
format standard, say it isnt so.  Next will come .MSO, its just like .OSM but 
with the subtle MicroSoft Openstreetmap changes to the existing format.




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

Re: [OSM-talk] 12nm territorial borders - useful or rubbish?

On Mon, Feb 14, 2011 at 1:22 PM, Frederik Ramm frede...@remote.org wrote:
 I'm not saying we should delete them; but whenever I see them on the map I
 tend to shrug and say well, seems like someone was trying out his PostGIS
 skillz, and somehow I have the suspicion that the 12nm line as depicted on
 our maps may be little more than that's what computer geeks do if you tell
 them the border is 12 miles out

Heh, the same thought has occurred to me.

I would add a fourth question: even assuming that we are all agreed
that this is valuable, properly computed data - do we want it shown in
the main Mapnik view? Is the international waters designation
important enough to show at that level?

Steve

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

Re: [OSM-talk] magical road detector to play with

On Mon, Feb 14, 2011 at 11:42 AM, David Murn da...@incanberra.com.au wrote:
 A program that came out of Microsoft, trying to slightly modify a
 defacto file format standard, say it isnt so.

Dude. It's 2011. We've moved on. Let's stop attacking Microsoft
employees when they come here to do something helpful, because of some
grudge from the mid 90s.

Thanks,
Steve

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

Re: [OSM-talk] 12nm territorial borders - useful or rubbish?

2011-02-13 Per discussione David Murn

On Mon, 2011-02-14 at 03:22 +0100, Frederik Ramm wrote:
 I've been thinking about the 12nm territorial borders on sea that we 
 have in many places, notably in Europe. Many of them seem to have been 
 auto-generated by simply placing a buffer around the coastline.
 
 My first question is, do they really have legal significance?

 For example, if I am inside this triangle between Scotland and Ireland, 
 will my legal status (concerning, say, fishing quotas, or whom I can 
 marry on board of my vessel, or whatever funny things influcenced by 
 international borders) be really any different from the status I had if 
 I moved my vessel 2 miles in either direction?

Try approaching by sea to within 13 miles of China, Iran or Pakistan,
then travel another 2 miles across the territorial border and see if the
locals think it makes a difference.

Im sure I remember reading a linked news story posted on this mailing
list about a soldier crossing into enemy country because of incorrect
mapping on his GPS.

 Would the UK coastguard have a good laugh when I claim to be in international 
 waters at that location?

If youre more than 12 miles from the coast (which is what is mapped)
then youre in international waters, why would they laugh at that fact?

 My second question is, assuming that indeed there is significance to the 
 12 nm boundary - should such auto-generated data be in OSM at all? If 
 you're out on the sea, should whatever navigational aid you carry not 
 compute by itself how far you are from the coast, rather than telling 
 you whether you're to the left or to the right of a previously computed 
 12nm line?

What happens if the international waters stretch further than 12nm in
some areas?  The generally accepted rule is that 12nm is the edge of
territorial waters, but by treaty/agreement this can be changed.

 I'm not saying we should delete them; but whenever I see them on the map 
 I tend to shrug and say well, seems like someone was trying out his 
 PostGIS skillz

A ships captain might look at a neatly laid out park and say 'why bother
putting each tree, thats just showing off that you can make pretty
patterns', in the same way that a non boating person might fail to see
the value in territorial water boundaries.

David


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

Re: [OSM-talk] 12nm territorial borders - useful or rubbish?

2011-02-13 Per discussione Anders Arnholm

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

2011-02-14 03:22, Frederik Ramm skrev:

 For example, if I am inside this triangle between Scotland and Ireland,
 will my legal status (concerning, say, fishing quotas, or whom I can
 marry on board of my vessel, or whatever funny things influcenced by
 international borders) be really any different from the status I had if
 I moved my vessel 2 miles in either direction?

Yes, I'm not sure abo9ut teh Uk or Irish rules in details but in and
around sweden if for example you are a small vessel, some of the
international shipping rules are not applied for you ship. Such as the
need to carry day signals. Outside the water limits these rules don't
applie any more and you can be fined. The data in the swedish borders
comes form a EU database, not looked deeper into it.

 http://www.eea.europa.eu/data-and-maps/data/maritime-boundaries


 Or are we, by using these auto-generated (and perhaps not
 human-reviewed?) borders, suggesting a precision that isn't there? Would
 the UK coastguard have a good laugh when I claim to be in international
 waters at that location?

Isn't the legal case same for everything? Hey officer my gps said the
was 90 here. Claming anything based on the map i think is wrong.

 And my third question is, assuming that there are really good reasons
 for having these lines in OSM - who takes care of updating them once the
 coastline is modified by a mapper? I think it is a rather unique
 situation to have that kind of data-derived-from-other-OSM-data in OSM
 itself, and thus this has many of the same problems that an import would
 have (i.e. the source data has changed, what now).

Who take resopsibilti to update any data, does these lines differ
really. The real line i then as well is not just 12nm outside the coast
but some kind of simplifactions of that 12 nm, also there are issues
when the line overlaps between two contries.

 I'd like to hear from people who tell me that yes, these borders are
 really useful to have ;)

I personally would love OSM to have much more usefull data even at sea.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Y0fEACgkQtbR3SXmySrferACeJXyo3VP39fjkSQOfY+7lWZGB
TXEAnjdSBHqIHmTfeuZ1fkko6ISvcu7F
=KLmX
-END PGP SIGNATURE-

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: [OSM-talk] 12nm territorial borders - useful or rubbish?

2011-02-13 Per discussione Stephen Hope

On 14 February 2011 16:52, David Murn da...@incanberra.com.au wrote:
 Would the UK coastguard have a good laugh when I claim to be in international
 waters at that location?

 If youre more than 12 miles from the coast (which is what is mapped)
 then youre in international waters, why would they laugh at that fact?

Actually, that's one of the areas where it's often changed.  If you
are in a bay, and the mouth of the bay closes enough that you can't
get in without going through territorial waters, it doesn't matter how
big the bay gets afterwards, all the waters inside it a belong to that
country also. There's an example here, and it looks like it is
displayed correctly, which makes me think this part of the boundary is
not auto-generated.

http://www.openstreetmap.org/?lat=44.52lon=-65.52zoom=8layers=M

The question would be if that rule applied in that little triangle or
not - it's not a bay, but it is impossible to get to without going
through territorial waters, so I'm not sure.

There's a number of other places were the border has obviously been
corrected - not auto-generated.  Are we sure any of it was?


Stephen

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

Re: [OSM-talk] magical road detector to play with

2011-02-13 Per discussione Alan Mintz


At 2011-02-03 09:17, Steve Coast wrote:

http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx


This is something that has the potential to greatly increase mapping 
productivity!


A couple of things:

1. When I run the sample 
http://magicshop.cloudapp.net/DetectRoad.svc/detect/?pt1=47.6274924080735,-122.119339391984pt2=47.6266897967272,-122.116431877412bbox=47.628475815791,-122.120927259721,47.6254135470002,-122.114489958085


It produces a road segment that is not very well centered. The imagery for 
this area is rather good (~0.06m/pel - zoom 21) and it should be a fairly 
easy case. Can someone look at this? Is it being too sensitive, not 
sensitive enough, etc.? Can some of the internal parameters be exposed so 
we can play with them?


2. When I try 
http://magicshop.cloudapp.net/DetectRoad.svc/detect/?pt1=47.6312440,-122.1126077pt2=47.6263360,-122.1179483bbox=47.632,-122.119,47.625,-122.109 
it complains Error Status Code: 'BadRequest' Details: The points are too 
close together. Even though these points are further apart (~700m) than 
the ones in the example.


--
Alan Mintz alan_mintz+...@earthlink.net


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

[talk-au] Where are the Australian OSM groups?

2011-02-13 Per discussione Paul Schulz

Greetings,

For some reason I get spammed with the following. Though I would pass it in.

Regards,
Paul Schulz

On Mon, Feb 14, 2011 at 5:04 AM, !i! snip wrote:
 Hi Paul,

 as you might know, the German division has a nice map of all local groups at 
 www.openstreetmap.de.
 Inspired by this one, I created an international version and a simple bot 
 collecting all together.

 I would be glad, if you could add details, if there are some OSM teams around 
 Australia.

 So if you put this on the page of your local meeting wiki page:
 http://wiki.openstreetmap.org/wiki/Template:User_group
 then you will appear after while here:
 http://ikaria.informatik.uni-rostock.de/mm337/osm/usergroups/

 regards
 Matthias

 --
 This e-mail was sent by !i! to PaulSchulz by the E-mail user function at 
 OpenStreetMap Wiki.


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

Re: [talk-au] Where are the Australian OSM groups?

On Mon, Feb 14, 2011 at 9:33 AM, Paul Schulz p...@mawsonlakes.org wrote:
 Greetings,

 For some reason I get spammed with the following. Though I would pass it in.

Answer: busy plotting secession somewhere.

Steve

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

[Talk-de] Anleitung für OsmAnd




 Hi !

hat einer von Euch schon einmal eine umfangreicheres Tutorial für OsmAnd 
gefunden (Sprache etc.) - am besten schon in Deutsch ?!?!?


Gruß Jan .-)


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

[Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art




 hi !

wenn man Luftbilder hat und Reihenhäuser hochzeichnen will, dann sind 
verschiedene Schritte erforderlich.


Für den einfachen Reihenhaus-Typ gibt es schon eine Vielzahl von Hilfen 
- bei anderen muss man versuchen sich die Schritte zu vereinfachen.


Nachfolgend zwei Haustypen für die ich die Schritte vereinfachen möchte 
- Ziel soll letztendlich die Aufteilung und Zuweisung von Hausnummern sein.


Block mit abgewinkelter Führung
http://www.openstreetmap.org/?lat=53.860721lon=10.651828zoom=18layers=M 
- Haus Klipperstraße 2-12



Reihenhaus mit mehreren Mehrfacheinheiten und Versatz zwischen 
aufeinander folgende Einheiten
http://www.openstreetmap.org/?lat=53.869335lon=10.656549zoom=18layers=M 
- Haus Schützweg 12-19


Es sollte dabei die Rechtwinkligkeit der Gebäude auch mit im Vordergrund 
stehen.


Vielleicht eine Aufgabe für diese winterliche Wetter an einem Sonntag.

Gruß Jan :-)



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

Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art

2011-02-13 Per discussione Steffen Wolf

Jan Tappenbeck schrieb:

 Nachfolgend zwei Haustypen für die ich die Schritte vereinfachen möchte 
 - Ziel soll letztendlich die Aufteilung und Zuweisung von Hausnummern sein.

 Reihenhaus mit mehreren Mehrfacheinheiten und Versatz zwischen 
 aufeinander folgende Einheiten
 http://www.openstreetmap.org/?lat=53.869335lon=10.656549zoom=18layers=M 
 - Haus Schützweg 12-19

Das ist einfacher, deshalb vorgezogen. Skizze etwa:

+--+--+
|12|13+--+--+
|  |  |14|15|
+--+--+  |  |...
  +--+--+

Ich wuerde den Block 12-13 zeichnen, mit dem Rechtwinkeltool (x) in JOSM
geht das ja schnell. Dann den zusaetzlichen gemeinsamen Punkt zwischen
13 und 14 setzen, eine Linie zum zweiten gemeinsamen Punkt ziehen, die
dann mit dem Rechtwinkeltool (x) in die gewuenschte Breite ziehen. Dann
nach Sueden erweitern.

Also als Zwischenschritt erstmal sowas:

--+
  +--+
  |  |
--+--+

Hier hat man Glueck, dass die Waende wohl alle senkrecht sind.

Mit dieser Vorgehensweise wuerden die Einzelhaeuser nacheinander
angereiht. Wenn schon alles irgendwie krumm und schief eingetragen ist,
hilft vielleicht der Orthogonalizer (Q).


 Block mit abgewinkelter Führung
 http://www.openstreetmap.org/?lat=53.860721lon=10.651828zoom=18layers=M 
 - Haus Klipperstraße 2-12

Sowas ist mir auch haeufiger untergekommen. Meist mit groesserem Winkel
und nicht geteiltem Eckhaus. Skizze etwa:


-+
10  / \
   /   \
--+  12 \
   \_+
\ _-
 +

Hier hab ich bisher immer die 10 komplett rechtwinklig gezeichnet, ragt
halt in der Ecke ueber.

-+
10   |
 |
-+

Dann die 12 auch rechtwinklig. Die beiden Flaechen ueberlappen sich
dann. Am besten vom gemeinsamen Knoten losgehen und die laengste Kante
zeichnen, damit die Richtung stimmt.

_+
10_- |\
 +   | \
--\--12 \
   \_+
\ _-
 +

Dann mit Join overlapping Areas (Shift-J) beide Gebaeude verschmelzen.

-+
  \
 10;12 \
--+ \
   \_+
\ _-
 +

Fuer ein Eckhaus wuerde das ja schon reichen. Wenn man auftrennen muss,
dann halt wieder auftrennen. Also beide Knoten markieren, (P) fuer Split
Way, und die beiden U-foermigen Halbgebaeude wieder zu Flaechen
vervollstaendigen.

Wenn der Winkel 90° ist, dann ragen die Gebaeudeecken ueber die
gegenueberliegende Seite heraus. Nach dem Verschmelzen muss die Ecke
also wieder entfernt werden. Einfach die drei Knoten auswaehlen und
loeschen.

Sowas etwa:
+
   / \
--+   +

Wenn sowas schon krumm und schief eingetragen vorliegt, ist Neuzeichnen
einfacher. Wer die alten Knoten- und Wege-IDs beibehalten moechte, kann
ja die neuen Wege mit den alten verbinden (J) und die Knoten
verschmelzen (M).


Adressdaten hab ich bisher mit Strg-C, Strg-Shift-V uebertragen und dann
die Hausnummer angepasst. Gibt's da Automatisierungen?


Eins noch: Bing nimmt Gebaeude mal von Norden, mal von Sueden auf,
dadurch entsteht an einigen Stellen, oft auch mitten im Reihenhaus, ein
Versatz. Hier ist Feingefuehl noetig.


Hoffe, das hilft erstmal weiter,
 stw
-- 
Natürlich können Sie sich zur Prüfung anmelden. Sie können aber auch mit
einer Luftmatratze raus auf den Atlantik.

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione M∡rtin Koppenhoefer

Am 13. Februar 2011 02:09 schrieb Frederik Ramm frede...@remote.org:
 Wenn man nicht gerade, wie Stephan, vor dem Problem steht, alles mit SQL
 machen zu wollen, dann ist es ja wohl trivial, die verschiedenen gaengigen
 Einheiten fuer ein bestimmtes Mass in einem Programm abzudecken.


Hier würde ich gerne mal einhaken, weil ich auch vor diesem (und
ähnlichen) Problemen stehe. Wie (an welcher Stelle im Prozess) kann
man die OSM-Werte am besten normalisieren?

Ich komme leider nicht aus dem Informatik-Umfeld und selbst triviale
Aufgaben erfordern für mich einiges an Recherche bzw. riskiere ich,
die Probleme suboptimal zu lösen. Ich nutze derzeit Osmosis, hole mir
damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit
einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit
osm2pgsql in eine Renderdatenbank einlese. Die Werte übernehme ich
dabei derzeit einfach so, wie sie aus der db kommen.

Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem
Import in die db). Aber welches
Programm/Vorgehen/Programmier-/Scriptsprache bietet sich dafür an? (Da
ich das sowieso neu lernen muss, habe ich die Qual der Wahl). Oder
sowas wie sed / awk? Wie macht Ihr das normalerweise? Ich würde z.B.
bei population gerne alles so trimmen, dass es echte Zahlen sind,
ohne Einheiten oder Quellenangaben im tag. Was ist die Methode, um das
möglichst schnell zu berechnen?

Für ein paar Anhaltspunkte, wie andere Leute hier vorgehen, wäre ich dankbar.

Gruß Martin

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)


Hallo,

M∡rtin Koppenhoefer wrote:

Ich komme leider nicht aus dem Informatik-Umfeld und selbst triviale
Aufgaben erfordern für mich einiges an Recherche bzw. riskiere ich,
die Probleme suboptimal zu lösen. Ich nutze derzeit Osmosis, hole mir
damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit
einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit
osm2pgsql in eine Renderdatenbank einlese. Die Werte übernehme ich
dabei derzeit einfach so, wie sie aus der db kommen.

Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem
Import in die db). 


Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen 
koennte, wenn einem das lieber ist.



Aber welches
Programm/Vorgehen/Programmier-/Scriptsprache bietet sich dafür an? (Da
ich das sowieso neu lernen muss, habe ich die Qual der Wahl). Oder
sowas wie sed / awk? Wie macht Ihr das normalerweise?


Normalerweise muesste man dafuer einen XML-Parser nehmen. Das ist auch 
nicht superkompliziert. Aber - und dafuer kriege ich regelmaessig 
Schelte von echten Programmierern - da Du es hier it dem immer 
gleichen Datenproduzenten zu tun hast, kannst Du auch die Annahme 
treffen, dass die Daten immer gleich formuliert sind, d.h., Du bekommst 
immer eine Zeile der Form


   tag k=population v=... /

fuer die Bevoelkerung. Das wiederum heisst, dass Du in einer beliebigen 
primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst. Ein einfaches 
Perl-Skript, das die Bevoelkerung trimmt, saehe z.B. so aus:


#!/usr/bin/perl

while()
{
if (/tag k=population v=(.*)/)
{
printf(tag k=\population\ v=\%d\ /\n, $1);
}
else
{
   print;
}
}

Nach diesem Muster waere es auch trivial, z.B. noch Leerzeichen zu 
entfernen, oder ein 123.000 zu einem 123000 zu machen:


...
if (/tag k=population v=(.*)/)
{
$p=$1:
$p =~ tr/. //d;
printf(tag k=\population\ v=\%d\ /\n, $p);
}
...

oder ein MW in W umzurechnen, usw.usw.

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

[Talk-de] Die neue OSM-Wochennotiz Nr. 30

2011-02-13 Per discussione sb-listen

Hallo,

die Wochennotiz mit Neuigkeiten aus dem OpenStreetMap-Universum ist da:

http://blog.openstreetmap.de/2011/02/osm-wochennotiz-nr-30/

Viel Spaß beim Lesen wünscht das gesamte Redaktionsteam! :-)

Stephan
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione Stephan Wolff


Moin!

Am 13.02.2011 00:54, schrieb Frederik Ramm:

Stephan Wolff wrote:

Die Kodierung der Leistung als Wert mit wählbarer Einheit ist
m. E. ein Designfehler.
Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen:


Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens
klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in
die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt
brauchst ;)


Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage,
etc. werden Zahlen ohne mitgeschriebene Einheit verwendet. Dadurch kann
man diese Werte relativ einfach auswerten, vergleichen oder sortieren.
Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig.
Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit
oder das Leerzeichen vor der Einheit vergisst oder 4 M statt 4 m
schreibt. In einer Datenbank überwiegen die Vorteile einfacher Zahlen
deutlich gegenüber ausgeschriebenen Einheiten  mit wählbarem Präfix.

Auch bei highway=Autobahn wäre klar ersichtlich, was gemeint ist,
aber sinnvoll sind solche Werte in OSM nicht.

Viele Grüße, Stephan


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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione Tobias Knerr

Am 13.02.2011 12:55, schrieb Stephan Wolff:
 Am 13.02.2011 00:54, schrieb Frederik Ramm:
 Stephan Wolff wrote:
 Die Kodierung der Leistung als Wert mit wählbarer Einheit ist
 m. E. ein Designfehler.
 Ich musste folgendes Ungetüm in SQL zur Umrechnung nutzen:

 Dann ist der Designfehler aber in Deinem Prozess - solange es wenigstens
 klar ersichtlich ist, was gemeint ist, musst Du halt vor dem Import in
 die Datenbank alles in Pferdestaerken umrechnen, oder was Du halt
 brauchst ;)
 
 Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage,
 etc. werden Zahlen ohne mitgeschriebene Einheit verwendet.

Die Aussage ist falsch. Gerade bei maxspeed ist es Standard, dass andere
Einheiten als km/h erstens verwendet und zweitens explizit
mitgeschrieben werden.

Diese Praxis ist auch absolut sinnvoll, da Mapper so auf einfache Weise
die vor Ort üblichen und auf einem Schild auch in dieser Einheit
gegebenen Werte eintragen können. Der Wert mit expliziter
Einheitenangabe ist zudem unmissverständlich - anders als Werte mit
impliziter Einheit, bei denen kein Rückschluss auf die Intention des
Mappers möglich ist.

Auch bei Längeneinheiten finden sich übrigens explizit eingetragene
Einheiten.

 Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig.

Der Aufwand ist größer, aber immer noch klein. Es ist ganz sicher keine
unzumutbare Hürde.

 Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit
 oder das Leerzeichen vor der Einheit vergisst

Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen
kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach
beides funktioniert.

Übrigens sind Abweichungen und Fehler, die man als solche erkennt, kein
ernsthaftes Problem. Schlimm sind Fehler, die man nicht erkennen kann -
etwa, wenn jemand eine einheitenlose Zahl einträgt und sich seine
Annahmen zu deren Bedeutung von den Annahmen desjenigen, der sie
auswertet, unterscheiden.

Wer der Vermeidung von Fehlern, die ein simpler Validator automatisch
erkennen kann, Vorrang vor der Vermeidung unsichtbarer Fehler gibt,
setzt in meinen Augen falsche Prioritäten.

 In einer Datenbank überwiegen die Vorteile einfacher Zahlen
 deutlich gegenüber ausgeschriebenen Einheiten  mit wählbarem Präfix.

In einer Datenbank, auf die eine produktive Anwendung direkt zugreift,
ja. Allerdings nicht in einer Datenbank für menschenlesbare Attribute,
die auch noch möglichst stabil gegenüber Fehlinterpretationen sein
sollte. Glücklicherweise ist das kein Widerspruch, da wir hier in aller
Regel von zwei verschiedenen Datenbanken sprechen.

Tobias Knerr

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione Tobias Knerr

Am 13.02.2011 12:21, schrieb Frederik Ramm:
 M∡rtin Koppenhoefer wrote:
 Ich nutze derzeit Osmosis, hole mir
 damit einige Elemente aus dem Planet und kombiniere das Ergebnis mit
 einem Italy-Extrakt zu einem komprimierten osm-xml, den ich mit
 osm2pgsql in eine Renderdatenbank einlese.
[...]
 Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem
 Import in die db). 
 
 Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen
 koennte, wenn einem das lieber ist.
[...]
 Normalerweise muesste man dafuer einen XML-Parser nehmen. Das ist auch
 nicht superkompliziert. Aber - und dafuer kriege ich regelmaessig
 Schelte von echten Programmierern - da Du es hier it dem immer
 gleichen Datenproduzenten zu tun hast, kannst Du auch die Annahme
 treffen, dass die Daten immer gleich formuliert sind, d.h., Du bekommst
 immer eine Zeile der Form
 
tag k=population v=... /
 
 fuer die Bevoelkerung. Das wiederum heisst, dass Du in einer beliebigen
 primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst.

Ich erwäge gerade auch, in Zukunft einige der Verarbeitungsschritte für
meine Software in die Vorverarbeitung zu ziehen, und der für mich
spontan naheliegendste Ansatz wäre, einen eigenen Osmosis-Task zu schreiben.

Gerade, wenn die Daten (wie bei Martin ja anscheinend auch) ohnehin
schon durch die Osmosis-Pipeline wandern, müsste sich das ja ohne
zusätzlichen Lese-/Schreibaufwand integrieren lassen. Ganz nebenbei wäre
es auch noch sauber, weil Osmosis das XML-Parsen übernimmt, und sollte
außerdem für alle von Osmosis lesbaren Dateiformate klappen.

Habe ich da ein Problem übersehen?

Tobias Knerr

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

[Talk-de] josm: merkwürdige shop-Icon




 Hi!

mit der aktuellen JOSM-Version hat sich eine Erscheinung noch vestärkt.

Shops sind jetzt weiterhin nur rote Kreise - jetzt monstermäßig groß!!!

Hat das einen Sinn oder habe ich da etwas nicht mitbekommen ?

Gruß Jan :-)


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

Re: [Talk-de] Werte in OSM besser ohne Einheit

2011-02-13 Per discussione Markus


Hallo Tobias,


vor dem Import in die Datenbank alles umrechnen


Ja.


Bei maxheight, maxwidth, maxspeed, width, voltage,
werden Zahlen ohne mitgeschriebene Einheit verwendet.


Numerisches Feld für Zahl,
Auswahlfeld für Einheit.

Bei Geo-Höhen braucht man zusätzlich noch das Bezugssystem.


die vor Ort üblichen und auf einem Schild angegebenen Werte


Idealerweise gibt es für jeden Schlüssel eine Definition,
incl. Einheit für numerische Werte.
Sind mehrere Einheiten möglich, gibt es dafür einen Wertekatalog.

Der Editor bietet dann ein numerisches Eingabefeld,
dahinter ist die Einheit angegeben.

Ist die Einheit variabel,
wird eine als Standard angeboten (je nach Sprachregion oder so),
Der Benutzer kann dies in den Einstellungen (oder über ein DropDown-Feld 
neben dem numerischen Eingabefeld) ändern.


Der Editor (oder das DB-Interface) rechnet dann die Eingabe in die 
Standardeinheit um, und schreibt Wert und Einheit in die DB.


Idealerweise prüft der Editor gleich noch Syntax und Wertebereich.

Wenn abweichend vom Einheitenkatalog beispielsweise in Tubpfingen das 
Tubpfige Unterschenkelmass anstelle von Meter verwendet wird, muss 
das halt der Benutzer vor dem Eintragen in ein gebräuchlicheres Mass 
seiner Wahl umrechnen.


Numerische Werte mit Buchstaben (5m, 5 m, 5 Meta)
oder Werte mit semikolon;separierter Einheit (5;m)
werden bei der Syntaxprüfung zurückgewiesen:
du meinst '5 Meter'? - und bei OK entsprechend weggeschrieben.
Falls etwas anderes gemeint war (beispielsweise 5 Mega-Zentimeter) dann 
erkennt das der Benutzer und kann es noch sinnvoll ändern.



wenn jemand eine einheitenlose Zahl einträgt


Ja, das ist für den Anwender unbrauchbar (Glaskugel).

Gruss, Markus

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

Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art

2011-02-13 Per discussione Walter Nordmann


Wo ist denn hier das Problem? 
Oder anders gefragt: Was willst du (jan) uns mit diesen Worten sagen?

gruss
Walter

-
33,33% aller Statistiken beruhen auf kleinen Datenmengen.
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Optimierung-von-Zeichnungsprozessen-Reihenhauser-der-besonderen-Art-tp6020521p6020885.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] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten

2011-02-13 Per discussione UMAX974

Hallo Liste,

Dem nun folgenden Schweigen auf meine Anfrage entnehme ich, dass ihr alle mit 
de GarminBaseCamp - so ihr es verwendet - keine Probleme habt. 
Wenn das so ist, würde mich interessieren, ob es etwas gibt, was ihr in eurem 
workflow anders macht als ich!
Könnt ihr mir darauf mal eine Rückmeldung geben?

Gruß UMAX974


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

Re: [Talk-de] Werte in OSM besser ohne Einheit

2011-02-13 Per discussione Tobias Knerr

Am 13.02.2011 14:37, schrieb Markus:
 Bei maxheight, maxwidth, maxspeed, width, voltage,
 werden Zahlen ohne mitgeschriebene Einheit verwendet.
 
 Numerisches Feld für Zahl,
 Auswahlfeld für Einheit.

Kann man so machen.

 Idealerweise gibt es für jeden Schlüssel eine Definition,
 incl. Einheit für numerische Werte.
 Sind mehrere Einheiten möglich, gibt es dafür einen Wertekatalog.

Haben wir ansatzweise im Wiki.

 Ist die Einheit variabel,
 wird eine als Standard angeboten (je nach Sprachregion oder so),
 Der Benutzer kann dies in den Einstellungen (oder über ein DropDown-Feld
 neben dem numerischen Eingabefeld) ändern.

Das wäre ein naheliegendes und sinnvolles Konzept.

Man kann es auch anders angehen, z.B. wie Potlatch 2 - der stellt bei
maxspeed Schilder mit den gängigen Werten zum Auswahl bereit, jeweils
einen Satz für km/h und mph. Das würde bei Längenangaben nicht so gehen,
aber bei maxspeed funktioniert es durchaus.

 Der Editor (oder das DB-Interface) rechnet dann die Eingabe in die
 Standardeinheit um, und schreibt Wert und Einheit in die DB.

Und genau mit diesem Detail wäre ich nun nicht einverstanden. Die Lösung
würde nur beim Eingeben funktionieren. Damit fängt das Leben einer
Eintragung in OSM aber erst an. Der Wert soll auch noch in der History
50 mph heißen, nicht 80.4672. Und im Daten-Layer. Und beim Download
in einen Editor, der keine solche Eingabemaske hat.

Der Schritt gehört eine Stufe weiter nach hinten - nicht zwischen Editor
und OSM-Datenbank, sondern zwischen OSM-Datenbank und Anwendung.

 Idealerweise prüft der Editor gleich noch Syntax und Wertebereich.

Ja, natürlich. Das kann er mit der aktuellen Lösung und Tags wie
maxspeed=50 mph auch problemlos tun.

Gruß,
Tobias Knerr

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione M∡rtin Koppenhoefer

Am 13. Februar 2011 12:21 schrieb Frederik Ramm frede...@remote.org:
 Das Präprocessing wäre also wohl an dieser Stelle sinnvoll (vor dem
 Import in die db).

 Ja - obwohl man es durchaus auch spaeter noch in der Datenbank machen
 koennte, wenn einem das lieber ist.


ja, teilweise versuche ich mich auch daran (aber bisher nur Kleinkram).


 primitiven Sprache, u.U. sogar sed/awk, arbeiten kannst. Ein einfaches
 Perl-Skript, das die Bevoelkerung trimmt, saehe z.B. so aus:

 #!/usr/bin/perl
...
 Bye
 Frederik


vielen Dank Frederik für die Anregungen und Beispiele, d.h. ich sehe
mir wohl mal Perl an ;-). Praktisch wird man vermutlich Zeile für
Zeile durchackern (bzcat) und in Kopie (entweder verändert oder nicht)
speichern.

Gruß Martin

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

[Talk-de] Mappen von (Nicht-)Geodaten

2011-02-13 Per discussione M∡rtin Koppenhoefer

Obwohl ich mich eigentlich als Inkludist bezeichnen würde (nach
gängigem WP-Schubladendenken) finde ich, dass bestimmte Dinge eher
schlecht in OSM aufgehoben sind. Dazu zähle ich z.B. Ways die sich auf
Kartenmaterial oder Luftbilder beziehen.

Z.B. http://www.openstreetmap.org/browse/way/39509794

Das ist wohl ein way, der soweit ich die tags richtig interpretiere,
bezeichnet, wo man Yahoo-Bilder in hires (was immer das heissen
soll) finden kann. So was finde ich perfekt in einer parallelen
Datenbank aufgehoben, da es praktisch keinen Bezug zu OSM-Daten gibt
(zumindest keinen direkten Bezug) und da es sich auch m.E. nicht um
Geodaten handelt.

Zu allem Überfluss ist der verlinkte Way (mittlerweile immerhin in der
10. Version) inzwischen mit unseren Geodaten (z.B. einem Track und
einem Fluss sowie der Schweiz-relation) verwoben, obwohl es da
kaum Bezüge geben dürfte.

Vermutlich gibt es noch mehr Dinge dieser Art, wie z.B. neulich aus
einem Kommentar zur Bing-Auflösungskarte von User Ant hervorging.

Diese Daten haben m.E. auch keine besonders lange Halbwertszeit, da
Yahoo jederzeit die zugrundeliegenden Rasterdaten aktualisieren kann.

Da mir in meinen Gegenden sowas bisher nicht untergekommen war, will
ich hier mal anfragen, ob das inzwischen Standard ist in OSM, oder ob
es sich um Ausnahmen handelt (der hier verwandte und im Wiki nicht
dokumentierte tag hires kommt immerhin 893 mal in der db vor).

Gruß Martin

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

Re: [Talk-de] Mappen von (Nicht-)Geodaten

2011-02-13 Per discussione Chris66

 schlecht in OSM aufgehoben sind. Dazu zähle ich z.B. Ways die sich auf
 Kartenmaterial oder Luftbilder beziehen.

Solange es eine parallele Meta-DB nicht gibt, ist das aber schon eine
Hilfe beim Mappen (äh Sat-Tracen).

Die Grenze zwischen Geo und nicht-Geo ist auch nicht sauber zu ziehen.

Sind PLZ-Gebiete zB. GeoDaten? Wiki-URLs? Öffnungszeiten? etc. etc.

Schönen Sonntag,
Chris


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

Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art





Hier hat man Glueck, dass die Waende wohl alle senkrecht sind.

Mit dieser Vorgehensweise wuerden die Einzelhaeuser nacheinander
angereiht. Wenn schon alles irgendwie krumm und schief eingetragen ist,
hilft vielleicht der Orthogonalizer (Q).





= den kannte ich schon einmal nicht !!!

Gruß jan :-)


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

Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art


Am 13.02.2011 15:09, schrieb Walter Nordmann:


Wo ist denn hier das Problem?
Oder anders gefragt: Was willst du (jan) uns mit diesen Worten sagen?

gruss
Walter

-
33,33% aller Statistiken beruhen auf kleinen Datenmengen.


HI !

nach meinem bisherigen Zeichenweg waren viele Schritte erforderlich die 
auf Dauer etwas nervig sind und da dachte ich das es vielleicht Wege 
gibt die das Hauszeichnen noch mehr vereinfachen.


Gruß Jan :-)


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

[Talk-de] JOSM: Ein Haus aufteilen




 Moin !

in Josm gibt es ein Plugin für Ein Haus aufteilen

Nun habe ich festgestellt das viele Reihenhäuser mit einer ganzen Ziffer 
anfangen und dann mit a-? die nächsten Häuser kommen.


Bei mir kommt eine Fehlermeldung.

Weiß einer ob das trotzdem irgendwie zu bewerkstelligen ist - ansonsten 
mache ich ein Ticket auf.


Gruß Jan :-)


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

Re: [Talk-de] josm: merkwürdige shop-Icon

2011-02-13 Per discussione Claudius


Am 13.02.2011 14:29, Jan Tappenbeck:

mit der aktuellen JOSM-Version hat sich eine Erscheinung noch vestärkt.
Shops sind jetzt weiterhin nur rote Kreise - jetzt monstermäßig groß!!!

Hat das einen Sinn oder habe ich da etwas nicht mitbekommen ?



Bitte nenne die genaue Revisionsnummer, der von dir getesteten 
JOSM-Version. Zudem wären mehr Details hilfreich.


Mit 3893 sehen bei mir Knoten, die mit shop=supermarket oder 
shop=estate_agent getaggt sind völlig normal (das erste mit 
Einkaufswagen, das zweite ohne Symbol) aus.


Claudius


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

Re: [Talk-de] Eigene Relation für POIs erlaubt?

2011-02-13 Per discussione Sven Anders

Am 10.02.2011 17:52, schrieb Manuel Reimer:

Mitja Kleider wrote:

Da das XAPI-Problem nicht von finanzieller Natur ist, gibt es noch
Hoffnung.

Naja, wenn es nur ein finazielles Problem wäre, könnte man ja Sammeln
gehn ;-)

Mal ein wenig OT:

Ich denke das Hauptproblem mit jeder neuer XAPI sind zwei Dinge:
* die ständig wachsende Datenmenge von OSM (und damit wachsende Indexe)
* die ständig wachsende Anfragemenge.

Im Vergleich dazu skaliert, der Geofabrik/Osmosis-Ansatz etwas besser,
da es für die wachsenden Anfragenmenge bereits etablierte und seit
Internet urzeiten Verfahren (FTP-Mirrors) gibt.

Die neue XAPI ist zwar noch nicht stabil (beim ersten Anlauf
war es ein Hardwareschaden), aber ich gebe ihr langfristig gute Chancen.
Ich würde es also erstmal damit versuchen, z.B.

http://azure.openstreetmap.org/xapi/api/0.6/*[man_made=*][bbox=9.64600,49.94625,9.70299,49.97297]

Beim zweiten Anlauf habe ich sofort ein Ergebnis bekommen. Komisch das
meine erste Anfrage sehr lange gedauert hat.

Hats sich damit deine Anfrage geklärt?
Ich würde dir auch den Osmosis/Geofabrik Ansatz empfehlen. Das hört sich
so dramatisch an, ist aber gerade für einen kleinen Ausschnitt recht
schnell gescriptet. Bitte melde Dich hier auf der Liste wenn du
Probleme damit hast (wo verstehst du was nicht?, wie sieht deine jetzige
XAPI-Anfrage aus?, Betriebssystem?) Ich gehe davon aus, das wir im
Zweifel damit nicht nur Dir sondern auch noch 10 weiteren OSMlern helfen
können die später irgendwann das ML-Archiv lesen.

Gruß
Sven

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

Re: [Talk-de] josm: merkwürdige shop-Icon


Am 13.02.2011 18:26, schrieb Claudius:

Am 13.02.2011 14:29, Jan Tappenbeck:

mit der aktuellen JOSM-Version hat sich eine Erscheinung noch vestärkt.
Shops sind jetzt weiterhin nur rote Kreise - jetzt monstermäßig groß!!!

Hat das einen Sinn oder habe ich da etwas nicht mitbekommen ?



Bitte nenne die genaue Revisionsnummer, der von dir getesteten
JOSM-Version. Zudem wären mehr Details hilfreich.


3893



Mit 3893 sehen bei mir Knoten, die mit shop=supermarket oder
shop=estate_agent getaggt sind völlig normal (das erste mit
Einkaufswagen, das zweite ohne Symbol) aus.

Claudius


schicke Dir direkt ein Bild !

Gruß Jan :-)


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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)


Hallo,

Tobias Knerr wrote:

Ich erwäge gerade auch, in Zukunft einige der Verarbeitungsschritte für
meine Software in die Vorverarbeitung zu ziehen, und der für mich
spontan naheliegendste Ansatz wäre, einen eigenen Osmosis-Task zu schreiben.


Eventuell kannst Du TagTransform entsprechend aufbohren. Das wuerden 
sicher noch mehr Leute nutzen wollen.



Habe ich da ein Problem übersehen?


Lediglich das, das Osmosis sich dem Programmieranfaenger unter 
Umstaenden nicht direkt erschliesst - und Martin schrieb ja, er koenne 
eh nichts und deshalb sei ihm jede Sprache gleich recht ;)


Osmosis ist halt ein Java-Programm nach Industriestandard - mit einigen 
Indirektionen, Factories, Interfaces, Implementationen mehr, als es 
einem Einsteiger naheliegend erscheinen wuerde.


Aber wenn man sowas regelmaessig macht, fuehlt man sich da natuerlich 
daheim ;)


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

[Talk-de] Polizei nutzt Openstreetmap

2011-02-13 Per discussione Christoph Wagner

Hallo Liste,

ich bin gerade von der Antinazidemo in Dresden wieder rein.
Was mir hier gerade eine Meldung wert ist, ist der Umstand, dass die Polizei 
mittlerweile Openstreetmap bei ihren Einsätzen benutzt.
Das ist mir heute erstmalig aufgefallen. Letztes Jahr hatten sie krude 
Stadtpläne vom Landesvermessungsamt, die schon älter waren.

Ich hab jetzt leider nicht geprüft, ob die Attribution korrekt war, aber ich 
geh mal davon aus (sah nach größerem Internetausdruck aus, da ist das ja 
automatisch dabei).

Natürlich haben auch die Demonstranten OSM-Pläne für die Orientierung benutzt, 
aber das gabs auch schon letztes Jahr.

Wenn jetzt aber schon die Polizei mitbekommen hat, dass die besten und 
aktuellsten Karten von Dresden, die man auch noch kostenlos bekommen kann, die 
von Openstreetmap sind, dann werte ich das als Würdigung unserer Arbeit.

Hat mir den Tag verschönert ;)

Grüße
Christoph



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

Re: [Talk-de] aio selber basteln - Tipp benötigt

2011-02-13 Per discussione Schorschi

Moin,

On Sat, 12 Feb 2011, Carsten Schwede wrote:

 wenn Du auf Deinem Navi die Eisenbahn nicht dargestellt bekommst, dann 
 liegt es an dem verwendeten Style und da mußt Du dran drehen. Da werden 
 offenbar im Style der AIO die Eisenbahnen auf eine Garminnummer gemappt, 
 die Dein GPS nicht darstellen kann. (Eisenbahn sollte Garmin-Typnummer 
 0x14 bekommen, dann gehts auch mit alten Geräten)

hm, ich habe jetzt eine Weile rumprobiert ... aber da scheint noch ein 
bißchen mehr zu klemmen - wie gesagt, hier habe ich ein nüvi 1390. Dieses 
klassische Bahnlinien-Symbol (0x39) will nicht - egal, ob ich nun die 
resolution nach oben oder unten ändere. Mit 0x14 geht's, aber auch nur in 
den drei höchsten Zoomstufen (egal, auf was resolution steht) - das ist 
mir ein bißchen wenig, ich finde Bahnlinien wesentlich wichtiger. 

Ich vermute mal, da es sich ja um ein Pkw-Navi handelt, dass die 
Darstellung noch irgendwo anders beeinflusst und unterdrückt wird. Das 
sieht mir doch recht zeitaufwändig auf, da weiterzukommen - oder hat da 
noch jemand einen guten Tipp, wo/wie man sinnvoll weiterprobieren kann?

(das sinnvollste ist wohl Hardware, auf der ein offenes Navi-System läuft 
... beim nächsten Mal dann :-)

Insgesamt scheint es da nicht so viel freie (im Sinn von quelloffen) 
Software am Markt ... Einen freien Typefile-Editor habe ich nicht gefunden 
- und wie bekomme ich ein .img-file mit freier Software geöffnet?

Mkgmap natürlich eine Ausnahme bildet. Und der Macher von cgpsmapper hat 
sein Projekt wohl bei sourceforge eingestellt - auf der Suche nach 
Mitprogrammierern.

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

Re: [Talk-de] aio selber basteln - Tipp benötigt

2011-02-13 Per discussione Chris66

Am 13.02.2011 21:30, schrieb Schorschi:

 bißchen mehr zu klemmen - wie gesagt, hier habe ich ein nüvi 1390. 

Ich würd' auf dem Nüvi mal eine Standard-nahe Karte (ohne Typfile)
probieren, zB. die von ComputerTeddy oder die Worldwide-Routable von
Lambertus.

Chris


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

Re: [Talk-de] aio selber basteln - Tipp benötigt

2011-02-13 Per discussione Carsten Schwede


Hi,

Am 13.02.2011 21:30, schrieb Schorschi:

Insgesamt scheint es da nicht so viel freie (im Sinn von quelloffen)
Software am Markt ... Einen freien Typefile-Editor habe ich nicht gefunden
- und wie bekomme ich ein .img-file mit freier Software geöffnet?


Der online Typfileeditor:

http://ati.land.cz/gps/typdecomp/editor.cgi

Freie Software zum öffnen und teilweise bearbeiten von img-Files

QLandkarte (für Linux und Win): http://www.qlandkarte.org/

Nicht freie Software (aber ganz praktisch zum öffnen von z.B. gmapsupp.img)

GPSMapEdit (für Windows): http://www.geopainting.com/en/

--
Viele Grüße
Carsten

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

Re: [Talk-de] aio selber basteln - Tipp benötigt

2011-02-13 Per discussione Ulf Lamping


Am 13.02.2011 21:30, schrieb Schorschi:

Ich vermute mal, da es sich ja um ein Pkw-Navi handelt, dass die
Darstellung noch irgendwo anders beeinflusst und unterdrückt wird. Das
sieht mir doch recht zeitaufwändig auf, da weiterzukommen - oder hat da
noch jemand einen guten Tipp, wo/wie man sinnvoll weiterprobieren kann?


Auf meinem Nüvi 200W scheint es da zwei Darstellungsmodi zu geben.

Während der Navigation werden eine ganze Reihe an Sachen ausgeblendet 
(egal was man auf der Karte eigentlich hätte) und ich habe keinen Weg 
gefunden dies zu ändern damit ich die Sachen doch sehe.


Wenn man einmal auf den Bildschirm drückt geht das Teil in einen anderen 
Modus und zeigt auf einmal viel mehr an, in etwa so viel wie die Outdoor 
Geräte. Nur navigieren ist dann nicht mehr.


Also entweder, oder :-(

Das gleiche Verhalten hat mein zumo 550 (Motorrad-Navi) auch.

Gruß, ULFL

P.S: Die gleiche Datei zeigt auf meinem Oregon 200 die Sachen übrigens 
so an wie gedacht - mit allen Details, die das Nüvi leider ausblendet.


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

[Talk-de] Südpol im Atlantik

2011-02-13 Per discussione Markus


Interessant:
Strahlenförmige Ländergrenzen, und beim Reinzoomen erscheint Südpol...
http://www.openstreetmap.org/?lat=-0.09lon=0.32zoom=6layers=M

Gruss, Markus

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

Re: [Talk-de] Mappen von (Nicht-)Geodaten

2011-02-13 Per discussione Wolfgang

Hallo,
Am Sonntag 13 Februar 2011 16:22:38 schrieb M∡rtin Koppenhoefer:
 Obwohl ich mich eigentlich als Inkludist bezeichnen würde (nach
 gängigem WP-Schubladendenken) finde ich, dass bestimmte Dinge eher
 schlecht in OSM aufgehoben sind. Dazu zähle ich z.B. Ways die sich auf
 Kartenmaterial oder Luftbilder beziehen.
 
 Z.B. http://www.openstreetmap.org/browse/way/39509794
 
 Das ist wohl ein way, der soweit ich die tags richtig interpretiere,
 bezeichnet, wo man Yahoo-Bilder in hires (was immer das heissen
 soll) finden kann. So was finde ich perfekt in einer parallelen
 Datenbank aufgehoben, da es praktisch keinen Bezug zu OSM-Daten gibt
 (zumindest keinen direkten Bezug) und da es sich auch m.E. nicht um
 Geodaten handelt.
 


Mich nerven die Dinger auch, aber mit dem Filter kann man sie wenigstens 
ausblenden. Einen Nutzen erkenne ich nicht in irgendwelchen Auflösungskarten.

Gruß, Wolfgang

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

[Talk-de] Spanien braucht OSM-Pflege

2011-02-13 Per discussione Oscar Orbe

Hello list,
Sorry for posting in English.
Here is a ranking of the cities/towns in Spain which need the most OSM love. 
Click 4 times on the last column to see them sorted:
http://bit.ly/eUkBpX
Now you finally have something to do in your spare time. You can legally use 
this WMS service:
http://www.idee.es/wms/pnoa/pnoa?
with the tags:
source=PNOAsource:date=2009
I myself will start with Cuenca.
Thanks,--Oscar



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

Re: [Talk-de] Garmin BaseCamp Version 3.1.4 (MAC OS) und OSM Karten

2011-02-13 Per discussione Wolfgang

Hallo,
Am Sonntag 13 Februar 2011 15:10:21 schrieb UMAX974:
 Hallo Liste,
 
 Dem nun folgenden Schweigen auf meine Anfrage entnehme ich, dass ihr alle
  mit de GarminBaseCamp - so ihr es verwendet - keine Probleme habt. Wenn
  das so ist, würde mich interessieren, ob es etwas gibt, was ihr in eurem
  workflow anders macht als ich! Könnt ihr mir darauf mal eine Rückmeldung
  geben?
 

Ganz einfach: Ich weiß nicht mal, was dieses base camp ist :-)

Ich gehe mal davon aus, das es sich um die leider übliche Garmin-Windows-
Klicki-SW handelt, die man nur mühsam zur Mitarbeit überreden kann und eher 
nicht braucht. Ich installiere alle Karten direkt im Navi bzw. auf der SD-
Karte und habe damit eigentlich keine Probleme.

Gruß, Wolfgang

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

Re: [Talk-de] aio selber basteln - Tipp benötigt

2011-02-13 Per discussione Wolfgang

Hallo,
Am Sonntag 13 Februar 2011 22:36:41 schrieb Ulf Lamping:
 Am 13.02.2011 21:30, schrieb Schorschi:
  Ich vermute mal, da es sich ja um ein Pkw-Navi handelt, dass die
  Darstellung noch irgendwo anders beeinflusst und unterdrückt wird. Das
  sieht mir doch recht zeitaufwändig auf, da weiterzukommen - oder hat da
  noch jemand einen guten Tipp, wo/wie man sinnvoll weiterprobieren kann?
 
 Auf meinem Nüvi 200W scheint es da zwei Darstellungsmodi zu geben.
 
 Während der Navigation werden eine ganze Reihe an Sachen ausgeblendet
 (egal was man auf der Karte eigentlich hätte) und ich habe keinen Weg
 gefunden dies zu ändern damit ich die Sachen doch sehe.
 
 Wenn man einmal auf den Bildschirm drückt geht das Teil in einen anderen
 Modus und zeigt auf einmal viel mehr an, in etwa so viel wie die Outdoor
 Geräte. Nur navigieren ist dann nicht mehr.
 
 Also entweder, oder :-(
 
 Das gleiche Verhalten hat mein zumo 550 (Motorrad-Navi) auch.
 
 Gruß, ULFL
 
 P.S: Die gleiche Datei zeigt auf meinem Oregon 200 die Sachen übrigens
 so an wie gedacht - mit allen Details, die das Nüvi leider ausblendet.
 

Bahnlinien werden im Nüvi 1490 auch nicht angezeigt, wobei das Colorado mit 
der gleichen Datei Bahnlinien anzeigt. 

Ich finde das zwar etwas unschön, da vor oder hinter der Bahn(-brücke etc) 
schon einiges mit Orientierung zu tun hat, aber ich kann damit vorerst leben. 
Bis zu einem Navi, dass OSM-konform ist...

Gruß, Wolfgang

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

Re: [Talk-de] Südpol im Atlantik

2011-02-13 Per discussione Stephan Knauss


On 14.02.2011 00:00, Markus wrote:

Strahlenförmige Ländergrenzen, und beim Reinzoomen erscheint Südpol...
http://www.openstreetmap.org/?lat=-0.09lon=0.32zoom=6layers=M


Die Software kann unendlich nicht darstellen. Eigentlich müsste alles 
nördlicher/südlicher von 85 Grad abgeschnitten werden.

So landet es dann eben bei 0/0

Stephan


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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione Stephan Wolff


Moin!

Am 13.02.2011 13:21, schrieb Tobias Knerr:

Am 13.02.2011 12:55, schrieb Stephan Wolff:

Am 13.02.2011 00:54, schrieb Frederik Ramm:

Stephan Wolff wrote:

Die Kodierung der Leistung als Wert mit wählbarer Einheit ist
m. E. ein Designfehler.


Dann ist der Designfehler aber in Deinem Prozess


Das sehe ich anders. Bei maxheight, maxwidth, maxspeed, width, voltage,
etc. werden Zahlen ohne mitgeschriebene Einheit verwendet.


Die Aussage ist falsch. Gerade bei maxspeed ist es Standard, dass andere
Einheiten als km/h erstens verwendet und zweitens explizit
mitgeschrieben werden.


Bei maxspeed hast du recht. Ich hatte nur im Wiki bei DE:Map_Features
nach nummerischen Daten geschaut. Dort und unter DE:Key:access werden
nur Werte ohne Einheit in km/h genannt.
Allerdings beruht hier die unterschiedlichen Einheiten auf anderen
nationalen Gesetzen und nicht auf einer willkürlichen Wahl des Mappers.


Bei Daten mit wählbaren Einheiten ist ein viel größerer Aufwand nötig.


Der Aufwand ist größer, aber immer noch klein. Es ist ganz sicher keine
unzumutbare Hürde.


Wollte man Osmarender beibringen, Einheiten bei width auszuwerten,
müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen.
Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen
(etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich
der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen
werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben.

Eine Festlegung der Einheit würde dagegen pro Objekt einmalig eine
triviale Umrechnung erfordern.


Zudem gibt es mehr Fehlermöglichkeiten, wenn der Mapper die Einheit
oder das Leerzeichen vor der Einheit vergisst


Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen
kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach
beides funktioniert.


Wer kann und will eine solche robuste Auswertung in SQL implementieren?


Wer der Vermeidung von Fehlern, die ein simpler Validator automatisch
erkennen kann, Vorrang vor der Vermeidung unsichtbarer Fehler gibt,
setzt in meinen Augen falsche Prioritäten.


Ein Validator kann einfacher auf Zahl als auf Zahl mit zulässiger
Einheit testen. Falsche Zahlen kann ein Validator nie erkennen. Eine
Einheit mitzuführen bringt keinen Vorteil.


In einer Datenbank überwiegen die Vorteile einfacher Zahlen
deutlich gegenüber ausgeschriebenen Einheiten  mit wählbarem Präfix.


In einer Datenbank, auf die eine produktive Anwendung direkt zugreift,
ja. Allerdings nicht in einer Datenbank für menschenlesbare Attribute,
die auch noch möglichst stabil gegenüber Fehlinterpretationen sein
sollte. Glücklicherweise ist das kein Widerspruch, da wir hier in aller
Regel von zwei verschiedenen Datenbanken sprechen.


Mapnik, Osmarender und sicherlich die meisten OSM-Anwendungen greifen
direkt auf die Texte der Tags zu. Dort müssten komplexere und langsamere
Abfragen implementiert werden.
Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle
einmal mit generator:output:electricity=100 kW und ein anderes Mal als
generator:output:electricity=0.1 MW beschrieben wird? Mir wäre
generator:output:electricity=0.1 mit der eindeutigen Definition
Werte in MW lieber.

Viele Grüße, Stephan


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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)


Hallo,

Stephan Wolff wrote:

Wollte man Osmarender beibringen, Einheiten bei width auszuwerten,
müsste man das Programm ergänzen und an hunderte Teilnehmer verteilen.
Für Mapnik sind unhandliche Umrechnungen nötig. Bei Datenbankabfragen
(etwa nach den 100 leistungsstärksten Kraftwerken) vervielfacht sich
der Aufwand. Diese Regeln müssen für jede Auswertung erneut durchlaufen
werden. Der Aufwand ist nicht klein und wird wohl meist unterbleiben.


Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden, 
egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner 
- nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig 
auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Der 
Mapper hat es eh schon schwer genug. Die Mapper sind bei uns die 
Arbeitspferde, denen muessen wir es so leicht wie moeglich machen.


Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper 
wuerde width=700cm eingeben, der Editor das auf 7m umrechnen, und 
der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht 
richtig ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach 
der Dezimalpunkt verschoben wird.)


Was Osmarender betrifft, es gab frueher einen Praeprozessor, den man vor 
Osmarender laufen lassen musste, um Segmente umzudrehen. Es gibt heute 
noch ein Skript, das Kuestenlinien schliessen muss, damit Osmarender 
damit arbeiten kann. Es gibt einen Postprozessor fuer Bezierkurven. Ich 
sehe nicht, wieso man nicht einen Einheiten-Umrechnungs-Praeprozessor 
schreiben soll (oder, wie vorgeschlagen, einen Osmosis-Task dafuer bauen).


Und an hunderte Teilnehmer verteilen, was meinst Du damit? Das ist 
doch bei uns Standard, dass Software veraendert wird und Leute sich eine 
neue Version runterladen. Das kann nun wirklich kein Argument sein.



Das ist eine Variation, mit der eine robuste Auswertung gut klarkommen
kann. Dann ist es auch keine zusätzliche Fehlermöglichkeit, weil einfach
beides funktioniert.


Wer kann und will eine solche robuste Auswertung in SQL implementieren?


Wenn SQL das falsche Mittel ist, dann muss die Auswertung eben anders 
implementiert werden. Es ist nicht die Aufgabe des Mappers, sich 
darueber den Kopf zu zerbrechen.



Ein Validator kann einfacher auf Zahl als auf Zahl mit zulässiger
Einheit testen. Falsche Zahlen kann ein Validator nie erkennen. Eine
Einheit mitzuführen bringt keinen Vorteil.


Da bin ich aber entschieden anderer Ansicht.


Mapnik, Osmarender und sicherlich die meisten OSM-Anwendungen greifen
direkt auf die Texte der Tags zu. Dort müssten komplexere und langsamere
Abfragen implementiert werden.


Die meisten Nutzer machen eh schon irgendwelche Vorverarbeitungsschritte 
- etwas mit Osmosis ausschneiden oder diffs mit Osmosis herunterladen 
zum Beispiel, da wuerde ein zusaetzlicher und bitte rechne alle 
Einheiten nach diesem Schema hier um-Schritt auch nicht stoeren. Die 
Reit- und Wanderkarte wie auch die OpenCycleMap haben sogar beide einen 
massiven Vorverarbeitungsschritt, in dem sie einen Grossteil der Tags 
auf eigene Nomenklatur umsetzen, bevor er mit osm2pgsl in die Datenbank 
wandert.


Meiner Ansicht nach ist das der richtige Weg, diese Vorverarbeitung 
einfacher zu machen, so dass sich jeder leicht zusammenbauen kann, 
welche Tags er will und wie er die gern ausgewertet haette (zum Beispiel 
spraeche auch nichts gegen ein aufgebohrtes osm2pgsql, das Tag-Werte 
erst an eine Umformroutine uebergibt, bevor die in die Datenbank kommen).


Der falsche Weg ist es, von Nutzern die Einhaltung von immer mehr Regeln 
zu verlangen, bloss weil der Datenauswerter ein einfacheres Leben haben 
will.



Hat ein Mensch einen Vorteil, wenn das selbe Modell einer Windmühle
einmal mit generator:output:electricity=100 kW und ein anderes Mal als
generator:output:electricity=0.1 MW beschrieben wird? Mir wäre
generator:output:electricity=0.1 mit der eindeutigen Definition
Werte in MW lieber.


Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie 
Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles 
Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar 
keine konkrete Zahl mehr, sondern nur noch small,medium,large. 
Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut 
umgehen kann und haette gern alles in vollen Watt. Deine 
Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung 
einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es 
geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd 
em Ruecken der Mapper ausgetragen wird) nicht.


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] Mappen von (Nicht-)Geodaten

2011-02-13 Per discussione Micha Ruh

2011/2/13 M∡rtin Koppenhoefer dieterdre...@gmail.com

 Obwohl ich mich eigentlich als Inkludist bezeichnen würde (nach
 gängigem WP-Schubladendenken) finde ich, dass bestimmte Dinge eher
 schlecht in OSM aufgehoben sind. Dazu zähle ich z.B. Ways die sich auf
 Kartenmaterial oder Luftbilder beziehen.

 Z.B. http://www.openstreetmap.org/browse/way/39509794

 Das ist wohl ein way, der soweit ich die tags richtig interpretiere,
 bezeichnet, wo man Yahoo-Bilder in hires (was immer das heissen
 soll) finden kann.


Fast richtig. Es bezeichnet, dass viele OSM-Daten innerhalb des ways von
Yahoo Bilder abstammen (Wälder/Häuser), welche bis z17 vorhanden sind.
Ausserhalb des ways stammen die Wälder, falls vorhanden,
von z13 Landsat-Satellitenbildern ab.
http://www.openstreetmap.org/?way=39509794



 So was finde ich perfekt in einer parallelen
 Datenbank aufgehoben, da es praktisch keinen Bezug zu OSM-Daten gibt
 (zumindest keinen direkten Bezug) und da es sich auch m.E. nicht um
 Geodaten handelt.


Wird für die neuen Bing-Luftbilder auch gemacht:
http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=46.68lon=8.41


Zu allem Überfluss ist der verlinkte Way (mittlerweile immerhin in der
 10. Version) inzwischen mit unseren Geodaten (z.B. einem Track und
 einem Fluss sowie der Schweiz-relation) verwoben, obwohl es da
 kaum Bezüge geben dürfte.


Jetzt nicht mehr.
Relationen mit mehr als 50 Members machen keinen Sinn und sollten verboten
sein.


Vermutlich gibt es noch mehr Dinge dieser Art, wie z.B. neulich aus
 einem Kommentar zur Bing-Auflösungskarte von User Ant hervorging.

 Diese Daten haben m.E. auch keine besonders lange Halbwertszeit, da
 Yahoo jederzeit die zugrundeliegenden Rasterdaten aktualisieren kann.


1,5 Jahre und immernoch gültig.



 Da mir in meinen Gegenden sowas bisher nicht untergekommen war, will
 ich hier mal anfragen, ob das inzwischen Standard ist in OSM, oder ob
 es sich um Ausnahmen handelt (der hier verwandte und im Wiki nicht
 dokumentierte tag hires kommt immerhin 893 mal in der db vor).


Für eine erste Einschätzung und Übersicht über die Qualität von den in
OSM erfassten Daten sind solche ways äusserst hilfreich,
oder weisst Du warum hier die Karte leer ist?
http://www.openstreetmap.org/?lat=45.8445lon=9.zoom=15

TL;DR:
Eigentlich unschön aber wichtige Mapper Hilfe.

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)

2011-02-13 Per discussione Ulf Lamping


Am 14.02.2011 01:40, schrieb Frederik Ramm:

Es ist trotzdem nicht akzeptabel, diese Arbeit den Mappern aufzubuerden,
egal wie trivial die Umrechnung ist. Da bin ich ein ziemlicher Hardliner
- nur weil irgendein Programmierer es nicht hinkriegt, die Daten richtig
auszuwerten, darf es fuer den Mapper nicht schwieriger werden. Der
Mapper hat es eh schon schwer genug. Die Mapper sind bei uns die
Arbeitspferde, denen muessen wir es so leicht wie moeglich machen.


Dann gehört sowas in die Editoren rein.

Es ist für einen Mapper wesentlich leichter, einen Zahlenwert und evtl. 
die Maßeinheit aus einer Drop-Down-Box auszuwählen, als irgendwas 
einzutragen und dann zu raten ob das jetzt gestimmt hat.


Das sowas später dann bestenfalls auf irgendwelchen Spezialkarten 
auftaucht die kaum einer kennt macht die Überprüfbarkeit durch den 
Mapper halt auch nicht leichter.



Auch eine Editor-Unterstuetzung hilft uns hier nicht, denn der Mapper
wuerde width=700cm eingeben, der Editor das auf 7m umrechnen, und
der Mapper sich dann beim naechsten wundern, wieso seine Angabe nicht
richtig ankam. (Noch schlimmer bei Einheiten, bei denen nicht einfach
der Dezimalpunkt verschoben wird.)


Wieso ein Mapper sich drüber wundern würde, wenn sein Editor aus 700cm 
beim Tag maxwidth automatisch 7m macht, müßtest du nochmal genauer 
erklären. Ich gehe eher davon aus, das dies dem Mapper die Arbeit eher 
erleichtern würde ah, hat er erkannt, dann stimmt das mit meiner 
Werteangabe also wohl. Vorausgesetzt, die Implementierung im Editor 
taucht was.


Vom verbiegen von geraden Zahlenwerten auf krumme Zahlenwerte in SI 
Einheiten (30 mph - 4x.xxx km/h) halte ich allerdings auch nix.


Dabei wird es immer Ausnahmen geben, z.B. wenn jemand abstruse Werte von 
einem alten Typenschild abschreibt und einträgt (weil er das nicht 
umrechnen kann oder will). Es sollte halt klar sein, das es dann eher 
nirgendwo angezeigt / ausgewertet wird.



Deshalb sollst Du ein Tool nutzen, das Dir die Daten so umbaut, wie sie
Dir am liebsten sind. Jemand anders will vielleicht fuer schnelles
Rendering die Generatoren in 3 Groessenklassen unterteilen und will gar
keine konkrete Zahl mehr, sondern nur noch small,medium,large.
Jemand drittes hat eine Software, die mit Kommazahlen nicht so gut
umgehen kann und haette gern alles in vollen Watt. Deine
Herangehensweise wuerde bedeuten, dass ihr Euch alle auf eine Loesung
einigen muesst - wenn statdessen jeder nimmt, was er kriegt, und es
geeignet umwandelt, gibt es diesen laestigen Abstimmungsbedarf (der aufd
em Ruecken der Mapper ausgetragen wird) nicht.


Alle drei von dir genannten Anwendungen wären mit einer eindeutigen 
Angabe (wie auch immer die aussieht) gut bedient und alle drei haben 
viel Arbeit beim aufdröseln von konfusen Strings die irgendwie Zahlen 
enthalten. Und das nicht nur bei diesem einen Tag, sondern bei ziemlich 
vielen!


Du tust hier so, als ob die bösen Anwendungsentwickler hier 
unmenschliches von den Mappern verlangen - dabei ist bei vielen Tags 
eher das Gegenteil der Fall ;-)


Mal davon abgesehen, das viele Tags meist sehr schnell konform werden, 
wenn sie von einer populären Karte angezeigt werden ...


Gruß, ULFL

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

Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)