date:20120727


Am 27.07.2012 10:02, schrieb Lester Caine:

Frederik Ramm wrote:

So, my questions to you are


I think there is a broad concensus

1. The concrete question: Should all name tag in the Crimea be in 
Russian (with
appropriate name:uk tags of course), even though the official 
language in

Ukraine is Ukrainian?

The raw name= tag shows what will be seen standing at the location.
It would help if there was also a lang=xx so we know what IS being used!

Again: I'm against lang for that purpose.
Examples:

name=London
lang=en
name:de=London

compared to:
name=London
name:en=London
name:de=London

Benefits:
- There aren't more tags involved,
- It's less error prone or better: it's equally error prone, but better 
to detect errors, as in the first alternative it's not possible to 
detect an error, if anyone only changes lang to any other language.

- Backward-compatibility to name is identical - just use it.
- Editor software could support it by enforcing users to add a language 
for the name-attribute.


regards
Peter

P.S.: I know that this does not solve the variants where more than one 
name is set to the name tag now, but I would leave that to other tags - 
e.g. name:format=ru - cr - en (de)


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

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione Miloš Komarčević

On Fri, Jul 27, 2012 at 10:43 AM, Peter Wendorff
wendo...@uni-paderborn.de wrote:

 Again: I'm against lang for that purpose.
 Examples:

 name=London
 lang=en
 name:de=London

 compared to:
 name=London
 name:en=London
 name:de=London


As far as I understand, this is not what is being proposed, but

name=London (or to be auto-generated from info below)
name:en=London
name:es=Londra
name:fr=Londres
lang=en

M

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

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione Miloš Komarčević

On Fri, Jul 27, 2012 at 9:02 AM, Lester Caine les...@lsces.co.uk wrote:
 That is the lang=xx tag for a higher level area, but we probably need
 official_lang and local_lang :)


I don't think this is a good idea. One tag that treats all the
languages the same is best.

Usually, when the use of the minority language is regulated by some
law in a particular administrative are, it becomes the _offical_
language and is treated exactly the same os the majority language. So
there is no distinction between them, they are both (or 3 or 4)
_official_ in that particular area. This scheme of 'official' vs.
'local' is confusing and would still leave the door open to edit wars
etc.

M

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

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione Lester Caine


Miloš Komarčević wrote:

wendo...@uni-paderborn.de  wrote:


Again: I'm against lang for that purpose.
Examples:

name=London
lang=en
name:de=London

compared to:
name=London
name:en=London
name:de=London


As far as I understand, this is not what is being proposed, but

name=London (or to be auto-generated from info below)
name:en=London
name:es=Londra
name:fr=Londres
lang=en


Exactly ... so that translations have a clean set of name:xxx direct from the 
tag without having to work out if the unidentified name is in some particular 
language, or it may be a combination of two anyway ...


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



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

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione Cartinus

On 07/27/2012 04:56 AM, Tirkon wrote:
 Ben Laenen benlae...@gmail.com wrote:
 With names it can be compacted as

 Avenue
   John Doe
  laan
 
 For me as a non native dutch/french this looks obfuscating.
 
 Is this the way you find it on the streetname-signs or only in OSM?
 For non native users of the map I would prefer to find the name tag in
 OSM exactly as on the signs. Because i.e. a foreign Chinese or Russian
 cannot read latin letters he only has the chance to compare the two
 pictures from the map and the signs. And if the naming is shortened he
 can only see different pictures.

http://www.google.nl/search?num=10hl=nlsite=imghptbm=ischsource=hpbiw=1232bih=944q=avenue+laanoq=avenue+laangs_l=img.3...2658.5105.0.6125.11.8.0.3.3.0.108.778.4j4.8.0...0.0...1ac.atAQp71k9x4#hl=nlsite=imghptbm=ischsa=1q=avenue+laan+street+signoq=avenue+laan+street+signgs_l=img.3...15183.22538.0.23226.12.12.0.0.0.0.85.875.12.12.0...0.0...1c.B9T3c9pCRespbx=1bav=on.2,or.r_gc.r_pw.r_qf.,cf.osbfp=c1d7c2c14d54ab18biw=1232bih=944

-- 
---
m.v.g.,
Cartinus

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

Re: [OSM-talk] FYI - Automated edit: footway - sidewalk

2012-07-27 Per discussione Gregory

On 26 July 2012 13:29, Frederik Ramm frede...@remote.org wrote:

 Hi,


 On 07/26/2012 02:08 PM, Gregory wrote:

 I was being a bit lazy/rushed and didn't see the login button.
 That forum could really do with some UI design work if anyone had oddles
 of time to work on it.


 Sorry but all the user interface experts are busy redesigning the OSM web
 page.

 Since about three years ago.

 Bye
 Frederik

 They must have got lost/eaten, let's send in another UI expert to find
them.

-- 
Gregory
o...@livingwithdragons.com
http://www.livingwithdragons.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione Ben Laenen

On Friday 27 July 2012 04:56:43 Tirkon wrote:
 Rue de
 
   Quelque Chose
   Iets
straat
 
 With names it can be compacted as
 
 Avenue
John Doe
   laan
 
 For me as a non native dutch/french this looks obfuscating.
 
 Is this the way you find it on the streetname-signs or only in OSM?

No, those are street signs (also, not all street signs will put them like that 
either). In OSM it's either name=Avenue John Doe - John Doelaan or the other 
way around.


 I mapped the street names in Sint-Genesius-Rode - Rhode-Saint-Genèse.
 I heard people nearly only speaking french there and was not aware of
 the heavy language dispute at that time. Thus I took the direction
 french - dutch. (As well I filled in the name.fr and name:nl tag.)
 Then a man living nearby told me that the belgium OSM community had
 decided to write first the upper and then the lower sign into the name
 tag. Thus he changed everything to dutch-french, which is the order
 from the signs. After that other people changed some street back to
 french-dutch. Since them I decided not to map there any more. ;-) I do
 not want to be part of the dispute.

Officially that municipality is Flemish, so Dutch-speaking, but has facilities 
for French. So according to the rules it should be Dutch - French. But yes, 
this creates some cases where the majority of the population is native in the 
other language...

Ben

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

Re: [OSM-talk] Naming disputes in Ukraine

2012-07-27 Per discussione john whelan

Locally we have English and French.  Unfortunately on one local street has
the following physical signs on it Prestone, Prestone Drive, Prom
Prestone Dr depending which sign you look at.

Personally I prefer the name:en etc it makes it easier to electronically
search for the name.  Having to know that to find the road you have to
enter Prom Prestone Dr or Promenade Prestone Drive makes it much more
difficult for people to use the map.

Cheerio John

On 27 July 2012 10:06, Ben Laenen benlae...@gmail.com wrote:

 On Friday 27 July 2012 04:56:43 Tirkon wrote:
  Rue de
  
Quelque Chose
Iets
 straat
  
  With names it can be compacted as
  
  Avenue
 John Doe
laan
 
  For me as a non native dutch/french this looks obfuscating.
 
  Is this the way you find it on the streetname-signs or only in OSM?

 No, those are street signs (also, not all street signs will put them like
 that
 either). In OSM it's either name=Avenue John Doe - John Doelaan or the
 other
 way around.


  I mapped the street names in Sint-Genesius-Rode - Rhode-Saint-Genèse.
  I heard people nearly only speaking french there and was not aware of
  the heavy language dispute at that time. Thus I took the direction
  french - dutch. (As well I filled in the name.fr and name:nl tag.)
  Then a man living nearby told me that the belgium OSM community had
  decided to write first the upper and then the lower sign into the name
  tag. Thus he changed everything to dutch-french, which is the order
  from the signs. After that other people changed some street back to
  french-dutch. Since them I decided not to map there any more. ;-) I do
  not want to be part of the dispute.

 Officially that municipality is Flemish, so Dutch-speaking, but has
 facilities
 for French. So according to the rules it should be Dutch - French. But yes,
 this creates some cases where the majority of the population is native in
 the
 other language...

 Ben

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

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

[OSM-talk] Fwd: [talk-au] Our friends down under need our help

2012-07-27 Per discussione Richard Weait

A thank you from a Perth mapper for the armchair mapping help from abroad.

There are many places where can help other mappers if you have a few
spare cycles.

-- Forwarded message --
From: Arie Paap wildmy...@gmail.com
Date: Thu, Jul 26, 2012 at 11:27 PM
Subject: Re: [talk-au] Our friends down under need our help
To: Andy Robinson ajrli...@gmail.com
Cc: talk-gb-westmidla...@openstreetmap.org, talk...@openstreetmap.org

Hi all,

On 20 July 2012 14:57, Andy Robinson ajrli...@gmail.com wrote:
 GB mappers, our Aussie friends need our help. Large swathes of Australia
 have been decimated by the redaction process so if like me your UK area is
 looking pretty clear please turn some attention to fixing some areas down
 under. If you do I'd suggest you subscribe to, or keep an eye on, the
 archive of the talk-au mailing list where requests and discussion on the
 redaction process are being made by some mappers.

snipped details on remapping

I've been fixing up parts of Perth where I live and thought I'd share
a few thoughts.

Large parts of Perth and the rest of WA were in decent shape after the
redaction. The worst effects are a lot of major roads which were
originally mapped by contributors who declined the new CTs or where
intersections and stretches of road were refined by tracing when
Nearmap became available; and In some areas suburb size areas were
originally traced by one contributor and have been largely lost. I
think also a lot of rural towns and rural highways are in poor shape.

However, I've seen a lot change over the last week. Personally, I've
repaired major roads in the southern suburbs (and filled in gaps in
adjoining residential roads) as well as try to repair the roads
through the city centre. Other local mappers have certainly been doing
there bit too. But why I'm writing this email is to say Thank You to
those UK and european mappers who've helped tracing roads in the
suburbs and rural towns and generally fixing up the map. While I don't
monitor edits throughout the Perth region via tools I have seen
problem areas be patched up and, wondering who might be working there,
found several UK contributors who've done significant work even though
none of us Perth residents have spoken up to ask for help or offer
guidance to support your efforts.

So once again Thank You.

So I'd like to say a few things about the map in Perth and WA.
 - First off the coverage is improving and I'm sure we'll get back to
most roads on the map pretty soon (particularly within greater Perth
region).
 - Street name coverage however has never been great and needs a few
more locals to survey. It's something I haven't done much of lately
but needs attention.
 - Road classification is a mess. It's something that's quietly
frustrated me ever since I discovered OSM and I really don't know
where to start to improve the situation.

And lastly: a few areas that could do with attention from anyone who
has time and energy to help:
 - Mandurah: http://osm.org/go/swll4QbE-
 - Pinjarra: http://osm.org/go/swlpYFKv-
 - Dunsborough: http://osm.org/go/swKnigAZ-
 - Carnarvon: http://osm.org/go/s1DjTuMg--
 - Broome: http://osm.org/go/tjy9_zp

I believe these areas have good Bing coverage and don't seem to have
much recent local activity (post redaction).
All your help is greatly appreciated.

Possibly Armadale: http://osm.org/go/sww6u5Qv-- and Midland:
http://osm.org/go/swxurea9-- could be included in this list though
these areas seem to have active local people so maybe not necessary.

There are many other rural towns which don't have complete street
coverage including South Hedland, Esperance, Gingin to name a few but
I think many of those weren't complete to start with.

I hope no one living and mapping in these towns is concerned about me
mentioning them here.

Kindest regards,

Arie.

P.S. Andy, if this mail doesn't make it through to
talk-gb-westmidlands would you please forward it on.

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

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

Re: [OSM-talk] Naming disputes in Ukraine


Am 27.07.2012 17:46, schrieb john whelan:
Locally we have English and French.  Unfortunately on one local street 
has the following physical signs on it Prestone, Prestone Drive, 
Prom Prestone Dr depending which sign you look at.


Personally I prefer the name:en etc it makes it easier to 
electronically search for the name.  Having to know that to find the 
road you have to enter Prom Prestone Dr or Promenade Prestone 
Drive makes it much more difficult for people to use the map.
But as long as the name:en etc are given additionally to name that 
shouldn't matter, as that should be found, too. Else I would consider 
that a bug in the search routine/software.


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

[OSM-talk] Tools to help find areas corrupted by redaction

2012-07-27 Per discussione Alan Mintz

For those of you that have been doing cleanup after the redaction, are you 
noticing anything in particular that could benefit from automated help?


For example, in an area I looked at yesterday, I saw a bunch of sawtooth 
formations, where a way would depart drastically from the true path of the 
road, then come back to a node on the road, then a node away again, etc. 
These nodes that were off the road were presumably those that had been 
moved to the correct alignment by a non-agreeing user, and were therefore 
moved back to their wrong locations by the bot.


Example: 
http://www.openstreetmap.org/?lat=33.744884lon=-117.608049zoom=18layers=M


I think these could be identified programmatically in a similar way as a 
smoothing algorithm: Calc the bearing b12 from p1 to p2, b23 from p2 to p3, 
and b24 from p2 to p4. If b12 is closer to b24 than b23 by a specified 
amount, the line is smoother without p3 in it, and is possibly corrupt. A 
little mathematical creativity can avoid having to calc the actual bearings 
with arctan on every point, since it's really the relative ratios that 
matter and not the actual values of the angles themselves.


Another thing is that these sawtooth ways tend to cross other ways without 
intersection, so this is a good indicator, too.


Lastly, I'm noticing orphan nodes in areas that need work.

These would make good layer(s) in the Geofabrik OSM Inspector.

Other ideas?

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


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

Re: [OSM-talk] Tools to help find areas corrupted by redaction

2012-07-27 Per discussione Toby Murray

On Fri, Jul 27, 2012 at 3:28 PM, Alan Mintz
alan_mintz+...@earthlink.net wrote:

 Another thing is that these sawtooth ways tend to cross other ways without
 intersection, so this is a good indicator, too.

 Lastly, I'm noticing orphan nodes in areas that need work.

Yes, and this can be tricky to pick out when you're just eyeballing an
area. I've been using the JOSM validator after doing a CTRL-a to
select everything I have downloaded. It is kind of noisy but just
looking at crossing ways and orphan nodes seems to find a lot of
problems.

I thought there was actually a debug tool that showed crossing ways
but I can't seem to find it now. I may have been thinking of the OSMI
Geometry layer but it doesn't show crossing ways.

 Other ideas?

I have been using my map of ways with a oneway tag but no highway tag
to find problem areas. Chances are wherever one of these ways exists,
there are probably more things to fix nearby. I just updated it last
night. Adding it as an imagery layer in JOSM lets me zoom in and
download a problem area quickly.

http://ni.kwsn.net/~toby/OSM/maps/redaction.html

Toby

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

Re: [OSM-talk] Tools to help find areas corrupted by redaction

2012-07-27 Per discussione Jonathan Waller


On 27/07/12 22:14, Toby Murray wrote:

On Fri, Jul 27, 2012 at 3:28 PM, Alan Mintz
alan_mintz+...@earthlink.net wrote:


...


I thought there was actually a debug tool that showed crossing ways
but I can't seem to find it now. I may have been thinking of the OSMI
Geometry layer but it doesn't show crossing ways.


The keepright tool at http://keepright.ipax.at has an intersections 
without junctions category.


Jonathan

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

Re: [OSM-talk] Tools to help find areas corrupted by redaction

2012-07-27 Per discussione Maarten Deen


Alan Mintz wrote:
For those of you that have been doing cleanup after the redaction, are you 
noticing anything in particular that could benefit from automated help?


- A large quantity of unconnected nodes. I've see a number of cases where the
way is gone but the nodes of that way are still present
- ways without tags or missing highway tags (that is probably more difficult to
automate)

Maarten



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

[OSM-talk] Problem with redaction layer of osminspector in JOSM

2012-07-27 Per discussione Pavel Melnikov

Hello everyone!
Today I tried to add geofabrik osminspector redactionbot layers into JOSM,
and followed procedures described in
http://wiki.openstreetmap.org/wiki/OSM_Inspector/WxS . However, it did not
work. JOSM loads some PNGs, but they do not contain any imagery, but text
Server Error, we are sorry for inconvenence 13. and similar stuff.
Can anyone share a working WMS link for JOSM? Or help some other way?

PS My WMS link is now wms:
http://tools.geofabrik.de/osmi/views/bot/wxs?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=bot_line_deleted,bot_line_modified,bot_line_superseded,bot_line_deleted_cp,bot_point_deleted,bot_line_modified_cp,bot_point_modified,bot_point_supersededSTYLES=SRS=EPSG:4326WIDTH={width}HEIGHT={height}BBOX={bbox}and
it does not work.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Redaction recovery

2012-07-27 Per discussione Brett Russell

Hi 

I have a Garmin Edge 305 that I can load into Basecamp rather than  Training 
Centre so can generate GPX files from Basecamp that work with OSM. 

Cheers 

Cheers
Brett Russell
PO Box 94
Launceston Tas. 7250
Australia
0419 374 971

On 27/07/2012, at 1:48 PM, Eric Rose er...@wamble.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 27/07/12 11:47, cam_...@fastmail.fm wrote:
 Hi Eric,
 
 Try gpsbabel, it's a handy tool that lets you convert ways / tracks /
 routes from one format to another:
 http://www.gpsbabel.org/
 
 I wish it worked, as that's how I used to do stuff with the old Edge 705
 and TCX format.
 
 Unfortunately, even though the GPSBabel site tells me that version 1.4.2
 supports FIT files with garmin_fit (for tracks at least), I get a Input
 type not recognised error when I try and convert a FIT file.
 
 I might have to download a converted file from ridewithgps after I
 upload it there.
 
 Eric
 
 
 It can be a little complicated to use, and there is a command line and a
 gui interface.
 The documentation on gpsbabel's website is very good.
 
 Cheers,
 Cam.
 
 I'm in Marrickville, but may be able to spend time cycling around and
 collecting traces in surrounding areas. Given that I haven't been an
 active mapper for a while, I'll have to re-familiarise myself with the
 tools again, and work out how to easily convert data from my Edge 800
 (FIT format) to GPX.
 
 All my previous mapping was done around Mullumbimby, and my primary
 focus is on recreating data from my old traces in that area.
 
 Eric
 
 
 - -- 
 Web-footed fascists with manical eyes,
 Ducks, Ducks, Quack-quack! Quack-quack!
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAlASDx4ACgkQ+lmeGwHCyRGkmgCdH1ROh3s7YTH4fgIwa0kPg8+/
 lQQAoJFRbprtoW2i4OJcmQ239Sx07EKA
 =OXzg
 -END PGP SIGNATURE-
 
 ___
 Talk-au mailing list
 Talk-au@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] Redaction recovery

2012-07-27 Per discussione Eric Rose

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/07/12 16:14, Brett Russell wrote:
 Hi
 
 I have a Garmin Edge 305 that I can load into Basecamp rather than
 Training Centre so can generate GPX files from Basecamp that work
 with OSM.

I've probably got my 305 somewhere, but no mounts for it. I only
recently gave away my 705 to my brother, and wouldn't go back to
either of them from the 800 (not as a cycling tool, anyway).
Converting from FIT won't be impossible, but more of a pain than I wish.

Eric

 
 Cheers
 
 Cheers Brett Russell PO Box 94 Launceston Tas. 7250 Australia 0419
 374 971
 
 On 27/07/2012, at 1:48 PM, Eric Rose er...@wamble.net wrote:
 
 On 27/07/12 11:47, cam_...@fastmail.fm wrote:
 Hi Eric,
 
 Try gpsbabel, it's a handy tool that lets you convert ways /
 tracks / routes from one format to another: 
 http://www.gpsbabel.org/
 
 I wish it worked, as that's how I used to do stuff with the old
 Edge 705 and TCX format.
 
 Unfortunately, even though the GPSBabel site tells me that version
 1.4.2 supports FIT files with garmin_fit (for tracks at least), I
 get a Input type not recognised error when I try and convert a
 FIT file.
 
 I might have to download a converted file from ridewithgps after I 
 upload it there.
 
 Eric
 
 
 It can be a little complicated to use, and there is a command
 line and a gui interface. The documentation on gpsbabel's
 website is very good.
 
 Cheers, Cam.
 
 I'm in Marrickville, but may be able to spend time cycling
 around and collecting traces in surrounding areas. Given
 that I haven't been an active mapper for a while, I'll have
 to re-familiarise myself with the tools again, and work out
 how to easily convert data from my Edge 800 (FIT format) to
 GPX.
 
 All my previous mapping was done around Mullumbimby, and my
 primary focus is on recreating data from my old traces in
 that area.
 
 Eric
 
 
 
 ___ Talk-au mailing
 list Talk-au@openstreetmap.org 
 http://lists.openstreetmap.org/listinfo/talk-au
 

- -- 
Web-footed fascists with manical eyes,
Ducks, Ducks, Quack-quack! Quack-quack!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlASRo4ACgkQ+lmeGwHCyRF+4ACgiTp8nRjaZalOBIWOIK/911tP
JeEAnRFF4KAr53Rki1m7U0eLYEV1rDJz
=RE9X
-END PGP SIGNATURE-

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

Re: [talk-au] City routing grid for Australia and the US

2012-07-27 Per discussione Leon Kernan

Hi, I've found an issue with this that will stop the Perth - Adelaide
results ever being green.
Google routes via a ferry across the Spencer Gulf, which gives it an
advantage.
Otherwise OSM is routing perfectly via Port Augusta, it's just longer than
the Google results.


On Sun, Jul 22, 2012 at 4:32 AM, Kai Krueger kakrue...@gmail.com wrote:

 Hello everyone,

 Inspired by the US 250 cities routing grid[1] used in the original TIGER
 cleanup in 2009, I have now created a similar routing grid for the USA
 and Australia.

 Australia: http://apmon.dev.openstreetmap.org/aus_routing_grid.html
 USA: http://apmon.dev.openstreetmap.org/us_routing_grid.html

 It takes the top cities of the country and calculates the routing
 distances between them and displays the result in a routing grid. It
 allows to check the top tear inter city road network. Unusually long
 routes are likely caused by broken data and indicates where things need
 fixing.

 In the grid, all routes that are more than 5% longer or slower than
 expected* are show in red, otherwise they are considered as
 superficially OK. The reference values are in brackets. If you click on
 the link, you will be sent to the detailed routing information.

 Unfortunately the situation, particularly in Australia, is pretty bad.
 In Australlia currently non of the routes between the top ten cities
 pass this criterion and in fact most of the routes can't be calculated
 at all any more due to disconnectedness of the road network.

 So for all those who are finished remapping their own area and are
 looking to help with a bit of armchair mapping, trying to get more of
 these routes green could be a good idea for arm chair mappers. Let's see
 how quickly we can get all of them green!

 The routing information is calculated using the Open Source Routing
 Machine ( http://map.project-osrm.org/ ) and if I am not mistaken,
 updates its data once a day. I will equally try and recreate those grids
 on a daily basis to help track progress on the remapping.

 Happy remapping,

 Kai

 * The time and distance that is expected is currently determined using
 google's directions API. Although not perfect by any means, it is
 probably the most reliable source for now as a reference.



 [1] http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities/routing_grid

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

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

Re: [Talk-br] Finalmente, dados da SPTrans abertos!

2012-07-27 Per discussione martin137

Olá Vitor,

 Quero fazer um post detalhado no Mapas Livres, mas, resumidamente, usamos a
 Lei de Acesso a Informação.
[...]

parabéns e muito obrigado já pelas informações. Quando você tiver tempo para 
escrever mais no seu site, por favor também explique a relação entre a Lei de 
Acessa à Informação (12527) e os direitos autorais (9610). Na primeira não 
achei nenhuma frase que mudou a segunda. Portanto, se os dados da SPTrans agora 
são domínio público (i.e. sem nenhuma proteção pela Lei 9610), eles sempre o 
eram (e a única diferença é que finalmente alguém (você) realmente queria 
disponibilizá-los ao povo).

O estranho é que (antes da Lei 12527) a prefeitura de Florianópolis reclamou 
quando alguém passou a lista dos pontos de ônibus para outras pessoas. Suponho 
que isso fosse em base da Lei 9610 (ou alguma ideia perversa de dados sigilosos 
mas não consigo imaginar isso). Mas como essa não mudou, os dados continuariam 
protegidos por direitos autorais. A única coisa que mudou é que posso pedir 
essa lista diretamente da prefeitura. A outra possibilidade é que essa lista 
nunca foi protegida pela Lei 9610 pois não é uma criação do espírito ou 
intelectual (Art. 7 e 8, respectivamente) e a prefeitura fez um drama sem 
justificativa.

Se todas as informações (não-sigilosas) de órgãos públicos de repente fossem 
domínio público, isso significaria que posso fazer qualquer coisa com 
publicações da prefeitura (o website, por exemplo)? Ou os dados da SPTrans são 
domínio público porque fazem parte dum ato oficial (Art. 8 IV)?

Agradeço quaisquer esclarecimentos sobre a relação entre as duas leis citadas 
acima. 

Abraço
Martin

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Markus


Hoi Stefan,

Danke für die Zusammenfassung:


* OSM-ID
* semantische IDs
* Ballast von PIDs
* OSM-IDs eine 100% OSM-interne Sache

und dann gabs noch die UUID

Eine ID muss m.E.
1. eindeutig sein (inkrementell oder UUID)
2. automatisch zugeordnet sein
3. persistent sein (nicht händisch editierbar)
4. möglichst stabil mit dem OSM-Objekt verbunden sein
5. möglichst stabil mit dem realen Objekt verbunden sein

Forderung 1 und 2 wird durch OID bzw. UUID erfüllt.

Forderung 3 wird durch OID erfüllt,
könnte auch durch geschützte UUID oder geschützte PID erfüllt werden.

Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie
ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen 
Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht, 
wiederhergestellt, dupliziert wird, und wie es von einem.


Das könnten wir anhand von konkreten und illustrierten Beispielen so 
erläutern, dass es auch für Anfänger und Gelegenheits-Mapper 
nachvollziehbar verständlich ist.


Der verbleibende Rest (Stabilität ist systemimmanent unklar, Mapper 
macht Fehler, etc) muss seitens der Anwendungs-SW geregelt werden, die 
zwei DBs verknüpft.


Neu:
Mapper müssen m.E. zunehmend verstehen lernen, dass sie nicht nur 
zeichnen, sondern eine DB erstellen :-)
Und dass das was sie tun, unmittelbare Auswirkungen auf die Anwendungen 
(Karten, Router, etc) hat.


Wir könnten hier schon mal beginnen, konkrete Beispiele zu sammeln, die 
einer Regelung bedürfen...

Und dann in einem zweiten Schritt entsprechende Regelungen zu finden,
und in einem dritten Schritt diese beispiele und Regeln illustriert 
beschreiben.


Gruss, Markus

PS: PIDs sind m.E. unnötiger Ballast.
(bzw ein Workaround für mangelhafte oder fehlende Regeln zu 4 und 5)

@Frederik: selbstverständlich müssen IDs projektintern geregelt sein.
Und selbstverständlich nach aussen so dokumentiert, dass Dritte sich 
darauf systematisch verlassen können.


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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Tobias Knerr

Am 27.07.2012 08:00, schrieb Markus:
 Eine ID muss m.E.
[...]
 4. möglichst stabil mit dem OSM-Objekt verbunden sein
 5. möglichst stabil mit dem realen Objekt verbunden sein

6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
verbunden ist.

Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit
einer Query-basierten Lösung praktisch automatisch gelöst würde, wird
von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer
einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu
dieser Frage ist es schon prinzipbedingt nicht lösbar.

 Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie
 ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen
 Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht,
 wiederhergestellt, dupliziert wird, und wie es von einem.

Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
eigentlich bezieht.

Gruß,
Tobias

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

Re: [Talk-de] Permanente/stabile OSM IDs!

Am 27.07.2012 08:20, schrieb Tobias Knerr:

Am 27.07.2012 08:00, schrieb Markus:

Eine ID muss m.E.

[...]

4. möglichst stabil mit dem OSM-Objekt verbunden sein
5. möglichst stabil mit dem realen Objekt verbunden sein

6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
verbunden ist.

Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit
einer Query-basierten Lösung praktisch automatisch gelöst würde, wird
von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer
einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu
dieser Frage ist es schon prinzipbedingt nicht lösbar.

Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie
ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen
Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht,
wiederhergestellt, dupliziert wird, und wie es von einem.

Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
eigentlich bezieht.

...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351

Klar - das könnte man auch einfacher haben, weil es letztlich genau der
Idee stabiler IDs nach overpass bzw. query2map entspricht und man dann
keine ID mehr in OSM einpflegen braucht, aber die entsprechend zu
referenzierenden Attribute mit der ID zu verknüpfen, ist soweit ich das
bisher sehe, weitgehend alternativlos.

Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende
Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf
dieses Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr
erkennbar.

Gruß
Peter

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

Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten

2012-07-27 Per discussione Albrecht Will



Frederik Ramm frede...@remote.org schrieb:

Hallo,

der eine oder andere mag vom redaction bot ueberrascht worden sein 
und wuenscht sich, er koennte noch mit den alten Daten weiterarbeiten. 
Das ist ja auch rechtlich gar kein Problem - solang man die 
CC-BY-SA-Lizenz einhaelt, kann man damit machen, was man will.

Ich habe auf

http://download.geofabrik.de/osm-before-redaction/

einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot 
bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der 
Nacht vollstaendig.) Die sind logischerweise statisch, sie werden nicht 
aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM 
insgesamt wieder von dem Bot erholt hat.

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 mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Markus


Moin Tobias,

Danke für diese wesentliche Ergänzung!


Eine ID muss m.E.

[...]

4. möglichst stabil mit dem OSM-Objekt verbunden sein
5. möglichst stabil mit dem realen Objekt verbunden sein


6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
verbunden ist.


Genau das sind die entscheidenden Fragen:


wann ist ein Restaurant noch dasselbe Restaurant
worauf bezieht sich die ID   eigentlich


Und da jedes externe Projekt seine eigene verschiedene Sicht hat,
ergeben sich folglich Missverständnisse.

Hier brauchen wir eine Definition, eine die von OSM ausgeht,
die möglichst eindeutig beschreibt wie wir unsere Daten verstehen.

Und dann brauchen wir eine auch für Anfänger und Gelegenheits-Mapper 
verständliche illustrierte Beschreibung.

Idealerweise sind die Regeln möglichst intuitiv verständlich.

Beispiel:
Wenn Du in einem Park Bäume zeichnest, dann kannst Du erst /einen/ Baum 
zeichnen, und diesen dann einfach mit Strg-d duplizieren und die Kopie 
an den Ort des nächsten Baumes verschieben.
Wenn dort aber schon ein Baum ist, musst Du erst prüfen, was für 
Eigenschaften er hat. Denn vielleicht ist er ja eine Tanne, und der Baum 
den Du einzeichnen willst ist eine Eiche. Oder der Baum wird vom 
Gartenbauamt gepflegt, und der den Du zeichnen willst von der 
Friedhofsverwaltung. Hier kannst DU zwar immer noch duplizieren, aber Du 
musst dann die nicht-zutreffenden Eigenschaften löschen bzw. ändern, und 
neu hinzugekommene Eigenschaften hinzufügen.



Query-basierte Lösung


Wie könnte sowas genau aussehen? (Beispiele)
Was ist der technische Aufwand?
Was sind Vor- und Nachteile?


Mit einer einzigen ID
für externe Projekte mit unterschiedlichen Auffassungen zu dieser Frage
ist es schon prinzipbedingt nicht lösbar.


Ja. Deswegen brauchen wir eine OSM-Definition zur Bedeutung der ID.

Gruss, Markus

- - - -

Beispiel *Haus*:

Status 1: (ID-1)
Das Haus gehört einem Besitzer,
der Besitzer hat es verpachtet an einen Restaurant-Betreiber,
das Restaurant heisst Linde

Status 2: (immer noch ID-1?)
Der Restaurant-Betreiber macht Pleite,
das Restaurant wird von einem neuen Pächter übernommen und heisst nun 
Hirsch


Status 3: (ID-?)
Auch der neue Pächter hat Schwierigkeiten.
Er verkleinert den Hirsch.
in der verbleibenden Haushälfte zieht ein Video-Verleih ein.

Status 4:
Der Pächter mit dem Video-Verleih übernimmt das ganze Haus durch Kauf,
aus dem Hirsch wird der Massagesalon Cleopatra.

Status 5:
Der neue Besitzer kauft auch noch die kleine Halle nebenan,
dort baut er eine Sauna ein, das Obergeschoss wird zur Bar mit 
Nebenzimmern, das Gelände bekommt einen begrünten Zaun und einen 
bewachten Eingang und einen Parkplatz. (Area)




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

Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten

2012-07-27 Per discussione Chris66

Am 27.07.2012 00:06, schrieb Frederik Ramm:

 Ich habe auf
 
 http://download.geofabrik.de/osm-before-redaction/
 
 einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot
 bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der
 Nacht vollstaendig.) 

Super, vielen Dank!

 Die sind logischerweise statisch, sie werden nicht
 aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM
 insgesamt wieder von dem Bot erholt hat.

Na Du bist ja optimistisch. ;-)

Chris




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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Manuel Reimer


Stefan Keller wrote:

Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
(oder wurde).


Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst 
braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben 
kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein 
uuid:building-Tag an. Der nächste interessiert sich vielleicht für die 
Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity dazu. 
Wenn Gebäude und Funktion einmal unabhängig voneinander werden (Restaurant zieht 
auf andere Straßenseite um), dann verbleibt das uuid:building dort wo es war und 
das uuid:amenity zieht mit dem Restaurant auf die andere Straßenseite um.


Gruß

Manuel


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

Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten

2012-07-27 Per discussione Mike Dupont

Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um
weiter mit cc-by-sa zu machen.
mike

2012/7/27 Chris66 chris66...@gmx.de

 Am 27.07.2012 00:06, schrieb Frederik Ramm:

  Ich habe auf
 
  http://download.geofabrik.de/osm-before-redaction/
 
  einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot
  bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der
  Nacht vollstaendig.)

 Super, vielen Dank!

  Die sind logischerweise statisch, sie werden nicht
  aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM
  insgesamt wieder von dem Bot erholt hat.

 Na Du bist ja optimistisch. ;-)

 Chris




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




-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
http://flossk.orgSaving wikipedia(tm) articles from deletion
http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten

2012-07-27 Per discussione Björn Sieper

Da gibt es übrigens nichtmal mehr einen Planet zum laden. Das ist also 
nach aktuellem Stand eine Einbahnstraße.


Ich wünsch dann mal noch viel Spaß.

Grüße
Am 27.07.2012 11:01, schrieb Mike Dupont:

Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um
weiter mit cc-by-sa zu machen.
mike

2012/7/27 Chris66 chris66...@gmx.de


Am 27.07.2012 00:06, schrieb Frederik Ramm:


Ich habe auf

http://download.geofabrik.de/osm-before-redaction/

einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot
bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der
Nacht vollstaendig.)


Super, vielen Dank!


Die sind logischerweise statisch, sie werden nicht
aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM
insgesamt wieder von dem Bot erholt hat.


Na Du bist ja optimistisch. ;-)

Chris




___
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] Geofabrik-Downloads fuer prae-Bot-Daten

2012-07-27 Per discussione Mike Dupont

es gibt einen planet von april :
http://pine02.fosm.org/planet/earth-20120401130001.osm.bz2

2012/7/27 Björn Sieper ac...@gmx.net

 Da gibt es übrigens nichtmal mehr einen Planet zum laden. Das ist also
 nach aktuellem Stand eine Einbahnstraße.

 Ich wünsch dann mal noch viel Spaß.

 Grüße
 Am 27.07.2012 11:01, schrieb Mike Dupont:

  Wenn ich auch editiern wollt, gibt es einen API server bei fosm.org um
 weiter mit cc-by-sa zu machen.
 mike

 2012/7/27 Chris66 chris66...@gmx.de

  Am 27.07.2012 00:06, schrieb Frederik Ramm:

  Ich habe auf

 http://download.geofabrik.de/**osm-before-redaction/http://download.geofabrik.de/osm-before-redaction/

 einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot
 bereitgestellt. (Upload ist noch nicht 100% durch, wird aber im Lauf der
 Nacht vollstaendig.)


 Super, vielen Dank!

  Die sind logischerweise statisch, sie werden nicht
 aktualisiert, und bleiben da auch nur ein paar Monate, bis sich OSM
 insgesamt wieder von dem Bot erholt hat.


 Na Du bist ja optimistisch. ;-)

 Chris




 __**_
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de






 __**_
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de




-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
http://flossk.orgSaving wikipedia(tm) articles from deletion
http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 10:38, schrieb Manuel Reimer:

Stefan Keller wrote:

Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
(oder wurde).


Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie 
zuerst braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr 
als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude 
will, dann legt er ein uuid:building-Tag an. Der nächste 
interessiert sich vielleicht für die Funktion des Gebäudes (z.B. 
Restaurant) und packt noch ein uuid:amenity dazu. Wenn Gebäude und 
Funktion einmal unabhängig voneinander werden (Restaurant zieht auf 
andere Straßenseite um), dann verbleibt das uuid:building dort wo es 
war und das uuid:amenity zieht mit dem Restaurant auf die andere 
Straßenseite um.


Wie soll das dann in der Praxis aussehen.
Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann 
uuid nehmen, oder gleich uuid:building. In der Regel ist es wohl so, 
dass der erste uuid setzt und alle weiteren dann Unterwerte...aber woher 
weiß ich dann als Unterwertsetzer, worauf sich die uuid bezieht?


Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ?

Henning


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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Manuel Reimer


aighes wrote:

Wie soll das dann in der Praxis aussehen.
Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann uuid
nehmen, oder gleich uuid:building.


Erst der Datennutzer sollte ein UUID setzen. Warum sollte ein Mapper nur so aus 
Spaß an der Freude überall UUID-Tags drankleben?


Und wenn der Datennutzer das Gebäude referenzieren will, dann direkt 
uuid:building. Ein reines uuid-Tag würde ich garnicht erst propagieren.



In der Regel ist es wohl so, dass der erste
uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich dann als
Unterwertsetzer, worauf sich die uuid bezieht?


Garnicht. Deshalb auch kein reines uuid-Tag.


Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ?


Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. 
Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen.


Gruß

Manuel


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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 12:09, schrieb Manuel Reimer:

aighes wrote:

Wie soll das dann in der Praxis aussehen.
Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann 
uuid

nehmen, oder gleich uuid:building.
Erst der Datennutzer sollte ein UUID setzen. Warum sollte ein Mapper 
nur so aus Spaß an der Freude überall UUID-Tags drankleben?
Das schreibt Manuel aber doch: Wenn ich ein Gebäude mit Restaurant 
indizieren möchte - also Datennutzer.
Und wenn der Datennutzer das Gebäude referenzieren will, dann direkt 
uuid:building. Ein reines uuid-Tag würde ich garnicht erst 
propagieren.
Also setze ich meine uuid:building? oder uuid:restaurant? oder 
uuid:buildingrestaurant?
Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, 
sondern das Restaurant zum Hirsch, dann setze ich 
uuid:buildingrestaurantname?


Ich bin, ehrlich gesagt, immer noch nicht überzeugt, wie das 
funktionieren soll.

In der Regel ist es wohl so, dass der erste
uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich 
dann als

Unterwertsetzer, worauf sich die uuid bezieht?

Garnicht. Deshalb auch kein reines uuid-Tag.

Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ?
Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht 
uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung 
auf zwei Nodes aufteilen.

Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt?
Langsam wird das System komisch...

Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 12:09, schrieb Manuel Reimer:
Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht 
uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung 
auf zwei Nodes aufteilen.


Betreiber ist der selbe. Ergo, wie du sagst eine uuid:amenity=1. Nun 
meint ein Mapper das ist aber blöd, mein Garmin zeigt das falsch an, ich 
teile das auf zwei Nodes auf. Was nun: beide nodes mit uuid:amenity=1 
oder mit unterschiedlicher uuid:amenity?


Aber egal wie ich es mache, als Betreiber des Portals würde ich doch nun 
gerne eine Meldung bekommen und mir die Sache anschauen um dann selber 
zu entscheiden, ob ich mich für das Cafe interessiere, das Restaurant 
oder gar für beides. Dementsprechend müsste ich dann meine Links anpassen.


Wenn ich keine uuid hätte sondern nur die osm-id, dann würde es auf das 
gleiche hinauslaufen.


Henning


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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Manuel Reimer


Peter Wendorff wrote:

Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, sondern das
Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname?


Nur uuid:amenity.


Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity.
Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen.

Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt?
Langsam wird das System komisch...


Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe einen 
anderen Namen wie das Restaurant. Zudem kann man nur so den Betreiber korrekt 
zuordnen.


Gruß

Manuel


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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 13:01, schrieb Manuel Reimer:

Peter Wendorff wrote:
Wenn ich eigentlich nicht einen Link zu das Restaurant da meine, 
sondern das

Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname?


Nur uuid:amenity.
Also ist der Link kaputt, wenn das Restaurant dann Zur Dorflinde heißt 
und statt gutbürgerlicher Küche auf einmal Thailändisch kocht.
Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht 
uuid:amenity.
Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei 
Nodes aufteilen.

Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt?
Langsam wird das System komisch...
Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe 
einen anderen Namen wie das Restaurant. Zudem kann man nur so den 
Betreiber korrekt zuordnen.
WENN das Cafe einen anderen Namen hat und von einem anderen Betreiber 
geführt wird, dann sind das meist in OSM sowieso zwei Nodes.
Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch 
Torten, Kuchen und Eis anbietet, ist ja durchaus üblich, selbst als eine 
einzelne Einrichtung - unter anderem mit identischem Betreiber.


Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!

2012-07-27 Per discussione Markus


Hallo Peter,


Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch
Torten, Kuchen und Eis anbietet, ist ja durchaus üblich


Hier hat unser Tagging-Schema noch Entwicklungsbedarf,
da Schlüssel pro Objekt ja nur einmal verwendet werden dürfen.
(es sei denn man macht so Konstrukte wie amenity=cafe;restaurant)

Auch werden oft in einem Attribut verschiedene Klassen vermischt.
(Funktion und Beschaffenheit bei Wegen beispielsweise)

Und Objekte enthalten Eigenschaften, die additiv abgebildet werden 
(Betreiber, Küche, Hotel|Restaurant|Cafe|Bar, etc) aber eigentlich 
relational sind und normalisiert werden müssten, damit das mit der ID 
klappt.


Anhand der ID-Frage wird das alles nur grad etwas deutlicher.

Gruss, Markus

PS: bitte keine Tagging-Disku lostreten - es geht um's System


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

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo Rainer

Am 27. Juli 2012 07:31 schrieb Rainer Kluge rklug...@web.de:
 On 26.07.2012 23:23, Stefan Keller wrote:
 Am 26. Juli 2012 18:57 schrieb Peter Wendorffwendo...@uni-paderborn.de:

 Vorausgesetzt, die PID/UUID wird mit kopiert

 Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der
 Normalfall für den einfachen Mapper.

 Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle
 abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer
 ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal
 nicht den Normalfall meint.

 Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für
 eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des
 Mappers funktionieren würde.

Die allermeisten Spezialfälle die gegen die UUID/PID angeführt werden,
müssen in der externen Datenbank gelöst werden. Solche hohe Ansprüche
bei der noch die Absicht des Mappers einbezogen wird, erfüllt kein
ID-System - und muss es auch nicht!

Es kommt mir vor als ob wir hier die Objektorientierung neu erfinden
(bzw. in Frage stellen) wollten, die gegenüber dem Relationalen Modell
postuliert hat, dass nicht die Gesamtheit aller Werte eines Tupels das
Tupel identifizieren, sondern dass jedem systeminternen Objekt eine ID
zugeordnet wird. Das ist die OSM-ID. Diese soll reorganisiert werden
können, ohne dass jedwelche Nutzer in Problem damit haben. Es gibt
also tatsächlich gute Gründe, dass die OSM ID eine 100% OSM-interne
Angelegenheit ist. Mit UUID/PID erhalten wir eine permanente/stabile
OSM-ID gegen aussen (oder externe ID oder UUID/PID) und decken
damit 80% der Fälle automatisch (nach der 80/20 Regel). Die restlichen
20% können in der externen Datenbank gelöst werden (dazu gab es hier
bereits interessante Vorschläge) und müssen - wie gesagt - letztlich
wieder von Menschen beurteilt werden.

Ich sehe hier folgende Vorstellungen: Für die einen (A) wird die
externe ID direkt in OSM mitverwaltet, bei der anderen ist eine
Softwarekomponente dafür zuständig. Letztere wiederum organisiert sich
(B1) eine solche externe ID, indem sie entweder versucht, mit den OIDs
klar zu kommen - oder (B2) aber solche externe ID in OSM. Ich
tendiere zu B2.

Nun diskutieren wir die verbleibenden 20% der Fälle - und was auch
immer herauskommt: 80% Automatisierung gegenüber vorher ist doch schon
mal nicht schlecht, oder?

 In allen nachfolgenden Fällen ist der Editor
 auf einen Entscheidung des Bedieners angewiesen:

 - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem
 gelöschten oder ist es ein anderes, neues Objekt?

Es ist identisch, denn die UUID/PID ist gleich. Jedwelche Ansprüche,
ob das nun mit der Realität oder der Absicht des Mappers übereinstimmt
überlassen wir den Fachdatenbanken/Nutzern. Wie gesagt: Der Normalfall
ist, dass der Mapper etwas verändert (verschiebt, ergänzt, etc.) wenn
es an allen Attributen (inkl. Geometrie) eine Änderung gibt und er
löscht, wenn ein Objekt der Realität gelöscht wird. Das gilt
selbstredend für gute Editoren und automatisierte Prozesse.

 - Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist
 das verschobene Originalobjekt?

Ähnlicher Spezialfall wie oben. Grundsätzlich tut man nach gesundem
Menschenverstand nicht ausschneiden und grad wieder am selbern Ort
dasselbe Objekt einfügen, nur um eine Vorlage zu haben für weitere
Objekte (vgl. unten). Da müsste ein schlauer Editor beim Einfügen nur
einem Objekt die UUID/PID vergeben und/oder ggf. eine Warnung ausgeben
(er erkennt das an der noch festzulegenden Konvention. dass das Tag
mit _id endet). Die anderen kriegen keine UUID/PID.

 - Kopieren und Einfügen, Löschen des Originals. Im Moment des Einfügens weiß
 der Editor noch nichts von dem späteren Löschen. Soll er die ID kopieren?
 Wenn ja, was passiert, wenn dann doch nicht gelöscht wird? Ein Konflikt beim
 Hochladen?

Bei diesem Spezialfall gibt der Editor schon beim Einfügen eine
Warnung aus (analog Fall vorher).

LG, Stefan

Am 27. Juli 2012 07:31 schrieb Rainer Kluge rklug...@web.de:
 On 26.07.2012 23:23, Stefan Keller wrote:

 Am 26. Juli 2012 18:57 schrieb Peter Wendorffwendo...@uni-paderborn.de:

 Vorausgesetzt, die PID/UUID wird mit kopiert


 Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der
 Normalfall für den einfachen Mapper.


 Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle
 abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer
 ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal
 nicht den Normalfall meint.

 Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für
 eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des
 Mappers funktionieren würde. In allen nachfolgenden Fällen ist der Editor
 auf einen Entscheidung des Bedieners angewiesen:

 - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem
 gelöschten oder ist es ein anderes, neues Objekt?

Re: [Talk-de] Permanente/stabile OSM IDs!

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 ...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
 projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
 = 12423528312313513412351341351

Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
Verknüpfung.
Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören.
Da ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.

LG, Stefan

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 27.07.2012 08:20, schrieb Tobias Knerr:

 Am 27.07.2012 08:00, schrieb Markus:

 Eine ID muss m.E.

 [...]

 4. möglichst stabil mit dem OSM-Objekt verbunden sein
 5. möglichst stabil mit dem realen Objekt verbunden sein

 6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
 verbunden ist.

 Das Problem wann ist ein Restaurant noch dasselbe Restaurant, das mit
 einer Query-basierten Lösung praktisch automatisch gelöst würde, wird
 von einigen ID-Befürwortern hier ja geflissentlich ignoriert. Mit einer
 einzigen ID für externe Projekte mit unterschiedlichen Auffassungen zu
 dieser Frage ist es schon prinzipbedingt nicht lösbar.

 Für Forderung 4 und 5 brauchen wir m.E. Regeln (eine Kultur), wie
 ein OSM-Objekt (Punkt, Linie, Fläche, Relation als Abbild einnes realen
 Objektes) aufgeteilt, zusammengeführt, verschoben, gelöscht,
 wiederhergestellt, dupliziert wird, und wie es von einem.

 Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
 eigentlich bezieht.

 ...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
 projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
 = 12423528312313513412351341351

 Klar - das könnte man auch einfacher haben, weil es letztlich genau der Idee
 stabiler IDs nach overpass bzw. query2map entspricht und man dann keine ID
 mehr in OSM einpflegen braucht, aber die entsprechend zu referenzierenden
 Attribute mit der ID zu verknüpfen, ist soweit ich das bisher sehe,
 weitgehend alternativlos.

 Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende
 Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf dieses
 Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr erkennbar.

 Gruß
 Peter


 ___
 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] Permanente/stabile OSM IDs!

Hallo Manuel

Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Stefan Keller wrote:

 Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
 OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
 (oder wurde).

 Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst
 braucht, legt sie an.

Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID.
Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal
an ein Objekt gehängt werden.

 Schon deshalb, weil ein Objekt ja mehr als eine UUID
 haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein
 uuid:building-Tag an. Der nächste interessiert sich vielleicht für die
 Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity
...

Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks Bedenken
Solch eine inflationäre Vergabe ist m.E. nicht nötig.
Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was
es in OSM gibt. Das löst ein Einfügen einer PID aus.
Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie
das intern lösen.
Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop
dann erhält das OSM-Objekt eine einzige PID.
In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle
auf das eine permanente/stabile OSM-Objekt zeigen.

LG, Stefan


Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Stefan Keller wrote:

 Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
 OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
 (oder wurde).


 Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst
 braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID
 haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein
 uuid:building-Tag an. Der nächste interessiert sich vielleicht für die
 Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity
 dazu. Wenn Gebäude und Funktion einmal unabhängig voneinander werden
 (Restaurant zieht auf andere Straßenseite um), dann verbleibt das
 uuid:building dort wo es war und das uuid:amenity zieht mit dem Restaurant
 auf die andere Straßenseite um.


 Gruß

 Manuel


 ___
 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] Permanente/stabile OSM IDs!

Wollte sagen:
Da ist Variante B1 oben *sinnvoller*, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.

Am 27. Juli 2012 16:16 schrieb Stefan Keller sfkel...@gmail.com:
Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
...Dann bauen wir die ID doch so auf, dass das eindeutig ist:
projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351

Das funktioniert möglicherweise für den WIWOSM-Fall zur Darstellung
aber sicher nicht für die Anwendungsfälle zur datenbankmässigen
Verknüpfung.
Die Änderung auch nur eines der Attributwerte (values) würde die ID zerstören.
Da ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.

LG, Stefan

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Am 27.07.2012 08:20, schrieb Tobias Knerr:

Am 27.07.2012 08:00, schrieb Markus:

Eine ID muss m.E.

[...]

4. möglichst stabil mit dem OSM-Objekt verbunden sein
5. möglichst stabil mit dem realen Objekt verbunden sein

6. eindeutig definieren, mit welchen Aspekten des OSM-Objekts sie
verbunden ist.

Und dazu braucht man eben eine Antwort auf die Frage, worauf sich die ID
eigentlich bezieht.

Klar - das könnte man auch einfacher haben, weil es letztlich genau der Idee
stabiler IDs nach overpass bzw. query2map entspricht und man dann keine ID
mehr in OSM einpflegen braucht, aber die entsprechend zu referenzierenden
Attribute mit der ID zu verknüpfen, ist soweit ich das bisher sehe,
weitgehend alternativlos.

Auch eine UUID-Lösung oder etwas der Art müsste eine entsprechende
Verknüpfung irgendwo halten (oder hat jemand eine andere Antwort auf dieses
Problem), nur wäre diese Verknüpfung durch den Mapper nicht mehr erkennbar.

Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!

Am 27.07.2012 16:16, schrieb Stefan Keller:

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:

Genau das, was ich will:
Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als
anderes Objekt betrachten, also SOLL die ID doch kaputtgehen.
Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein
anderes Objekt betrachten, also SOLL die ID kaputtgehen.
Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
betrachten, also SOLL die ID kaputtgehen.

Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße
geht, reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM
drinsteht und sich niemand zusätzlich um die Pflege irgendeines
ID-Systems kümmern muss.

Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht
mir auch die alte OSM-ID für 80% der Fälle aus - das will ich aber
üblicherweise nicht.
Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
Kriterien, und die kann ich in Attributen fassen, die dann einer ID
ähnlich sind.

Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.
Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API
schon, ohne zusätzliche Tags oder Attribute.

Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!

Solche Fragen, ob es bei der Änderung eines Restaurantnamens nun
dasselbe Objekt ist oder nicht, stellen sich bei allen Systemen, sogar
bei simplen Adressdatenbanken. Das würde ich im Zweifelsfalle, den
Fachdatenbanken überlassen.
Alle sind sich ja einig, das OSM  relativ grosszügig ist und man
zunächst einfach mal das taggen, was man sieht.

An dieser Stelle möchte ich nochmals eine Idee von Frederik
adaptieren, die er schon am 22. Juli 2012 22:58 schrieb Frederik Ramm
frede...@remote.org formuliert hat.
...
 Was aber eine gute Idee waere:

 Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit
 und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente
 Schluessel - seien das UUIDs oder Nummern oder sonstwas. Zu OSM hin benutzt
 diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland
 erfunden wurde, sondern ursrpuenglich mal von Tim Alder mit seinem query to
 map angedacht worden war).

 Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und den
 dann ueberall benutzen.

 Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat
 dieses Vorgehen den Vorteil, dass alle Links in der Datenbank regelmaessig
 automatisiert ueberprueft werden koennen: Sind sie noch gueltig? Zeigen sie
 noch auf genau 1 Objekt, oder mittlerweile auf 0 oder 2? Es waere trivial,
 in dieser Datenbank eine Liste zu generieren mit allen kaputten Links; es
 waere sogar moeglich, diese nach Nutzungsintensitaet zu sortieren, so dass
 viel genutzte Links von Freiwilligen sofort repariert werden koennen, wenn
 sie kaputt gehen. Es waere sogar denkbar, in dieser Datenbank das letzte
 bekannte gute Ergebnis aus OSM zu cachen fuer jeden Link, so dass man,
 selbst wenn bei OSM was kaputt geht, dem Anfrager immer noch wenigstens eine
 alte Version ausliefern kann.

Wie gesagt, bin ich immer noch der Meinung, dass die zwei anderen
Alternativen vorziehen, nämlich dass sich das Interface (ich nenne es
LinkedOSMDB) entweder (B1) halt mit OIDs herumschlägt oder (B2) eine
PID auch im OSM-Objekt einführt.

Analog zur Idee oben, könnte die LinkedOSMDB Listen anbieten, wo
Freiwillige mithelfen beim Reparieren und Entscheiden, was nun Sache
ist.

LG, Stefan

Am 27. Juli 2012 13:43 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 27.07.2012 13:01, schrieb Manuel Reimer:

 Peter Wendorff wrote:

 Wenn ich eigentlich nicht einen Link zu das Restaurant da meine,
 sondern das
 Restaurant zum Hirsch, dann setze ich uuid:buildingrestaurantname?


 Nur uuid:amenity.

 Also ist der Link kaputt, wenn das Restaurant dann Zur Dorflinde heißt und
 statt gutbürgerlicher Küche auf einmal Thailändisch kocht.

 Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht
 uuid:amenity.
 Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes
 aufteilen.

 Also einen Node auf zwei aufteilen, weil die UUID sonst nicht passt?
 Langsam wird das System komisch...

 Nicht nur die UUID passt nicht, sondern eventuell hat ja auch das Cafe
 einen anderen Namen wie das Restaurant. Zudem kann man nur so den Betreiber
 korrekt zuordnen.

 WENN das Cafe einen anderen Namen hat und von einem anderen Betreiber
 geführt wird, dann sind das meist in OSM sowieso zwei Nodes.
 Ein Cafe/Restaurant, das also nicht nur kocht, sondern eben gerade auch
 Torten, Kuchen und Eis anbietet, ist ja durchaus üblich, selbst als eine
 einzelne Einrichtung - unter anderem mit identischem Betreiber.

 Gruß
 Peter


 ___
 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] Permanente/stabile OSM IDs!

Hallo

Am 27. Juli 2012 16:52 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Am 27.07.2012 16:16, schrieb Stefan Keller:

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:

...Dann bauen wir die ID doch so auf, dass das eindeutig ist:

projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351

Genau das, was ich will:

Ok. Dann bin ich reden wir aber von ganz verschiedenen Anwendungsfällen :-

Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes
Objekt betrachten, also SOLL die ID doch kaputtgehen.

Stimmt. Das ist ein gerechtfertigtes Löschen und einfügen.

Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
Objekt betrachten, also SOLL die ID kaputtgehen.

Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele
zusammengetragen, wo die Koordinaten sich ändern, in dem ganze
Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass
es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle
verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer
dieser Verschiebung nicht traut, kann selber nachschauen - das aber
nicht auf Kosten der anderen verlangen, dass die Bushaltestelle
damit à priori eine andere sei.

Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
betrachten, also SOLL die ID kaputtgehen.

Das sind alle Systeme gleich.

Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht,
reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Das ist kein Anwendungsfall, um den es mir hier geht.

Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht
und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern
muss.

Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir
auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise
nicht.
Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
Kriterien, und die kann ich in Attributen fassen, die dann einer ID ähnlich
sind.

Nein: Ich möchte lediglich eine permanente/stabile ID anbieten und die
Kriterien, nach denen das getan wird den Nutzern überlassen.
Ich möchte einzig eine Lösung, welche nach aussen unabhängig ist von
OSM-IDs und nach der OSM-DB eindeutig ist in Bezug auf das OSM-Objekt.
Daher kommt eine (nicht von aussen ersichtliche) Kombination von Tags
und ein Ausschluss nicht-mit-normalen-Tags-identifiziertbarer
OSM-Objekte nicht in Frage.

Dies gesagt, halte ich aber immer noch ein Türchen offen für
Argumente, die für B1 sprechen, bei der die Interface-DB (LinkedOSMDB)
sich mit OIDs herumschlägt.

Da[s] ist Variante B1 oben, bei der gegen die OSM-DB die OID verwendet
wird und gegen aussen eine UUID/PID angeboten wird.

Genau - und die haben wir im Prinzip mit der Stable ID der Overpass-API
schon, ohne zusätzliche Tags oder Attribute.

Die Overpass-API ist alles andere als stabil gemäss meinen Kriterien.
Das wäre dann Lösungsvariante B3.

LG, Stefan

Am 27. Juli 2012 16:52 schrieb Peter Wendorff wendo...@uni-paderborn.de:
Am 27.07.2012 16:16, schrieb Stefan Keller:

Hallo

Am 27. Juli 2012 08:55 schrieb Peter Wendorff wendo...@uni-paderborn.de:

...Dann bauen wir die ID doch so auf, dass das eindeutig ist:

projekt-id[amenity=restaurant;addr:street=Schlemmerstraße;addr:housenumber=12;addr:postcode=21243;addr:city=Cooktown;name=OSMDiner][bbox=...]
= 12423528312313513412351341351

Genau das, was ich will:
Wenn das Restaurant umzieht zur Hausnummer 24, dann will ich es als anderes
Objekt betrachten, also SOLL die ID doch kaputtgehen.
Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
Objekt betrachten, also SOLL die ID kaputtgehen.
Wenn es kein Restaurant mehr ist, will ich es nicht mehr als solches
betrachten, also SOLL die ID kaputtgehen.

Wenn es mir nur um ein beliebiges Restaurant in der Schlemmerstraße geht,
reicht mir [amenity=restaurant;addr:street=Schlemmerstraße].

Der Knackpunkt ist doch, dass diese ID letztlich implizit in OSM drinsteht
und sich niemand zusätzlich um die Pflege irgendeines ID-Systems kümmern
muss.

Wenn ich ein Objekt mit egal welchen Attributen betrachten will, reicht mir
auch die alte OSM-ID für 80% der Fälle aus - das will ich aber üblicherweise
nicht.
Wenn ich ein Objekt referenziere, dann tue ich das anhand bestimmter
Kriterien, und die kann ich in

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 16:23, schrieb Stefan Keller:

Hallo Manuel

Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:

Stefan Keller wrote:

Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
(oder wurde).

Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst
braucht, legt sie an.

Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID.
Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal
an ein Objekt gehängt werden.


Schon deshalb, weil ein Objekt ja mehr als eine UUID
haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein
uuid:building-Tag an. Der nächste interessiert sich vielleicht für die
Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity

...

Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks Bedenken
Solch eine inflationäre Vergabe ist m.E. nicht nötig.
Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was
es in OSM gibt. Das löst ein Einfügen einer PID aus.
Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie
das intern lösen.
Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop
dann erhält das OSM-Objekt eine einzige PID.
In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle
auf das eine permanente/stabile OSM-Objekt zeigen.

Oh, das ist gut.
Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID 
klebt, z.B. die ID, die das Objekt schon aus osm hat.
Solange mein Bot der schnellste ist, bin ich immer der erste und alle 
anderen müssen damit klarkommen.


Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle 
Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs 
gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle 
unterstützen.


Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!

Lieber Peter

Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 27.07.2012 16:23, schrieb Stefan Keller:
...
 Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop
 dann erhält das OSM-Objekt eine einzige PID.
 In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle
 auf das eine permanente/stabile OSM-Objekt zeigen.

 Oh, das ist gut.
 Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt,
 z.B. die ID, die das Objekt schon aus osm hat.
 Solange mein Bot der schnellste ist, bin ich immer der erste und alle
 anderen müssen damit klarkommen.

Ich habe niemals von einem Bot gesprochen, sondern dass die
Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt
wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt.
Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein
OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die
ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie
oben z.T. oben diskutiert worden sind.

 Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle
 Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs
 gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle
 unterstützen.

Ja; die Variante B1 mit der OSM-ID als Link zwischen Interface-DB und
OSM behalte ich im Auge.

LG, Stefan

Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 27.07.2012 16:23, schrieb Stefan Keller:

 Hallo Manuel

 Am 27. Juli 2012 10:38 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:

 Stefan Keller wrote:

 Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle
 OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird
 (oder wurde).

 Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie
 zuerst
 braucht, legt sie an.

 Dann meinen wir dasselbe mit PID und deiner Auffassung von UUID.
 Üblich ist aber m.E. die Auffassung, dass UUIDs nur ein einziges Mal
 an ein Objekt gehängt werden.

 Schon deshalb, weil ein Objekt ja mehr als eine UUID
 haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er
 ein
 uuid:building-Tag an. Der nächste interessiert sich vielleicht für die
 Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity

 ...

 Das scheint mir aber zu weit zu gehen und hier verstehe ich Frederiks
 Bedenken
 Solch eine inflationäre Vergabe ist m.E. nicht nötig.
 Ich stelle mir das so vor, dass die Fachdatenbank einfach nimmt, was
 es in OSM gibt. Das löst ein Einfügen einer PID aus.
 Wenn eine andere Fachdatenbank damit nicht leben kann, dann muss sie
 das intern lösen.
 Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop
 dann erhält das OSM-Objekt eine einzige PID.
 In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle
 auf das eine permanente/stabile OSM-Objekt zeigen.

 Oh, das ist gut.
 Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt,
 z.B. die ID, die das Objekt schon aus osm hat.
 Solange mein Bot der schnellste ist, bin ich immer der erste und alle
 anderen müssen damit klarkommen.

 Danke - benutzen wir doch einfach die OSM-ID direkt und lassen alle
 Datenbanken damit klarkommen, das läuft nämlich auch hier wieder aufs
 gleiche raus: Die Funktionalität zum Klarkommen müssen dann alle
 unterstützen.

 Gruß
 Peter


 ___
 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] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate

2012-07-27 Per discussione Hartmut Holzgraefe

On 07/26/2012 11:41 AM, Frederik Ramm wrote:

 Ich hab jetzt bei den roten Sachen noch die Moeglichkeit eingebaut, sie
 von der Karte zu werfen, mit einem Muelleimer-Icon

irgendwie ist alles was ich gestern gelöscht habe heute wieder da, und
auch mein Löschliebling, die Humboldtstraße in Bielefeld, ist jetzt auf
meinem Laptop wieder rot obwohl ich die heute morgen auf meinem Desktop
noch einmal gelöscht habe?

http://tools.geofabrik.de/osmi/?view=redactionbotlon=8.51703lat=52.02503zoom=16overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted

-- 
hartmut

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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 17:15, schrieb Stefan Keller:

Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes
Objekt betrachten, also SOLL die ID kaputtgehen.

Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele
zusammengetragen, wo die Koordinaten sich ändern, in dem ganze
Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass
es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle
verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer
dieser Verschiebung nicht traut, kann selber nachschauen - das aber
nicht auf Kosten der anderen verlangen, dass die Bushaltestelle
damit à priori eine andere sei.
Wenn ich dich richtig verstehe, ist es dir/dem Projekt also egal, wenn 
das OSM-Objekt von Hamburg nach Berlin verschoben wird? Wenn ich das 
Projekt betreiben würde, würde mich diese Änderung schon interessieren.

Mein Gedankengang wäre dieser:

OSM-DB, gib mir mein Objekt mit der ID x
Dann prüfe ich, ob das Objekt noch da ist, wo ich es vermute, ob es noch 
die Eigenschaften hat, die ich vermute und dann nutze ich diese Infos. 
Wenn nicht möchte ich eine Info bekommen und dann 
nachschauen/nachschauen lassen.


Wie eng ich die Grenzen setze, muss ich mir dann überlegen.

Henning


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

Re: [Talk-de] Permanente/stabile OSM IDs!


Am 27.07.2012 17:31, schrieb Stefan Keller:

Lieber Peter

Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de:

Am 27.07.2012 16:23, schrieb Stefan Keller:

...

Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop
dann erhält das OSM-Objekt eine einzige PID.
In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle
auf das eine permanente/stabile OSM-Objekt zeigen.

Oh, das ist gut.
Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt,
z.B. die ID, die das Objekt schon aus osm hat.
Solange mein Bot der schnellste ist, bin ich immer der erste und alle
anderen müssen damit klarkommen.

Ich habe niemals von einem Bot gesprochen, sondern dass die
Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt
wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt.
Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein
OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die
ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie
oben z.T. oben diskutiert worden sind.

Das funktioniert aber nicht.
Ich bin dummerweise das zweite Projekt, das eine ID auf ein OSM-Objekt 
braucht, und dummerweise ist die aber anders definiert, weil ich 
wirklich das Gebäude aufgrund der historischen Bausubstanz meine, die 
PID aber dummerweise auf das Restaurant verweist.
Wenn ich von der LinkdOSMDB keine ID für meine Zwecke kriege, habe ich 
nichts gewonnen.
Wenn ich von der LinkdOSMDB nur dann eine ID kriege, wenn zufällig sonst 
niemand anders vorher eine hatte, habe ich nichts gewonnen.
In beiden Fällen muss ich nämlich doch eine Fallback-Lösung 
implementieren, die der von mir gewünschten ID entspricht, womit wir 
wieder beim Anfang wären.


Gruß
Peter

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

Re: [Talk-de] Permanente/stabile OSM IDs!