Re: [OSM-talk] upload from cvs

[Sarah Hoffmann]

On Fri, Sep 11, 2009 at 10:46:42PM +0200, Peppo Herney wrote:
 Hello,
 
 from the swiss alpin club i got a csv file with all the alpin huts.
 It looks like this
 
 name;url;ele;lon;lat;tourism;operator
 Aarbiwak 
 SAC;http://www.sac-pilatus.ch;2731;8.152199642;46.55547325;alpine_hut;SAC
 Capanna Adula 
 CAS;http://www.capanneti.ch/tedesco/tedesco.html;2012;8.995795439;46.49909694;alpine_hut;SAC
 Albert-Heim-Hütte 
 SAC;http://www.albert-heim-huette-sac.ch;2541;8.46345456;46.60896248;alpine_hut;SAC
 
 and has 153 records
 They gave permission to put it on osm.
 should i just upload it with with something like 
 http://svn.openstreetmap.org/applications/utils/import/csv2osm/csv2osm.pl
 or better convert it to an osm file to load in josm and do some last checks? 
 Which tool can i use?

According to tagwatch there are 133 alpine huts mapped already in
Switzerland, so you certainly should verify the import manually. If
you could make the converted osm file available somewhere, local 
mappers could help adding the missing data.

In any case, I forwarded this to talk-ch.


 By the way: The elevation is in CH1903. I also have the WGS84 transformation 
 and osm suggests to use it in http://wiki.openstreetmap.org/wiki/Key:ele 
 Yet, if people in switzerland look at the elevation and then on the sign at 
 the hut, it might look wrong, if i don't put CH1903 elevation.

I dare say that most of the ele tags in Switzerland are taken from
the hiking posts at the moment, so I'd keep the CH1903 data for
consistency. Maybe we should add a note in the wiki somewhere?

Sarah

 
 Thanks for your inputs
 
 Peppo
 
 -- 
 mobil: +41765310394
 home: +499113606687
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

[Sarah Hoffmann]

On Thu, Sep 27, 2012 at 04:59:27PM +0100, THEVENON Julien wrote:
 For major part of French contributors we are adding buildings and other 
 details not related to cadastre, so having one account per kind of edit will 
 be really painfull.. but it it will not be for people that just perform raw 
 building imports !

I don't know which data you have been looking at, but let's ask
Nominatim, shall we?

For France we have:
  raw buildings indexed27337552
  other objects indexed 3799339
---
Total number of objects indexed31136891

Objects are real word objects here: highways, pois, boundaries etc.
In other words, for 7 imported buildings you manage to map one 
non-cadastre object. So indeed, I would agree that French
contributors do map other details. 
Occasionally. Very. Occasionally.

[referring to separate import accounts]
 This is the real problem for us.

For the sake of completeness: planetwide there are currently
152 million objects. Which means 1/6th of the planet consists of
French buildings. Now, there is a real problem.

Whatever use all those balconies, patios and swimming pools might
have in the future, right now in the present the cadastre import
has become a major nuissance for anybody who wants to use OSM data.
It wastes lots of bandwidth and CPU time. If it wasn't for the
cadastre imports, we'd still be able to keep the 32bit id space
for nodes for another year or two, which would save a lot of hard
disk space for a lot of people.

Just some food for thought. Now please don't let me stop you from
continuing to complain about how all those import rules make your 
life so much harder.

Sarah

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

[Sarah Hoffmann]

On Thu, Sep 27, 2012 at 10:21:38PM +0100, THEVENON Julien wrote:
  De : Sarah Hoffmann lon...@denofr.de
  I don't know which data you have been looking at, but let's ask
 Nominatim, shall we?
 
 Ok, so by example could you extract stats from Grenoble instead of whole 
 France ? I thinks this quite representative of cities where there are 
 buildings and quite a lot of details.

Grenoble (as in relation 80348) has 13199 raw buildings and 10160 other
objects indexed. So, yes, this seems to be an example where the cadastre
data was put to very good use. But the fact remains that this does not
happen in most of the rest of France. The larger part of cadastre data
is just dumped into the data base never to be touched again by any mapper.

(For reference: for the entire planet there are approx. two other objects
for each raw building. This ratio holds even for Germany.)

 Concerning discussions about separated accounts I`m sure that there is a good 
 reason behind that but it was perhaps decided for cases that do not match 
 French one. What we are trying to do here is to discuss to understand why 
 this rule has been done ( that's why we are asking for a list of issues that 
 import Guidelines Rules want to address ) and if it is possible to find a 
 solution both  satisfy the goal you have and that do not create problems for 
 good-will french mapppers that spend time to perform clean cadastre 
 integration. I`m convinced ( or at least I hope )that you don`t create this 
 rule to make French mappers crazy.

The main problem is that you are asking for an exception to the import
rules on the grounds that your imports are small and carefully manually
checked and augmented with non-cadastre data. The numbers simply don't
support your claims. In fact, they say that the cadastre import is the
largest import OSM currently has to deal with, if it is not even the
largest import OSM ever had to deal with. If the French community could
admit that it would be a big step towards resolving the conflict.

Nobody contests that the cadastre situation is special.
There is no question that you have been thinking about this import very
carefully. The amount of work you have put in the development of tools
for it is admirable and you put a lot of effort into monitoring the
progress, so it certainly is not completely dead data. Still, the amount
of data you add is more than could be possibly ever looked over and
amended by the French community. The Germans did have a bit of a head
start and so far managed to 'only' add about 13 million objects to the
database, half of what you have added in buildings.

I do think that Richard's proposal presents a fair compromise for you.
Those who only want to add a bit of data for their home town can do so
without the hassle of creating a second account but those who import the
data on a larger scale without the chance to ever check what they import
locally must adhere to the import guidlines and do so on a special 
account. The barrier of entry that creates is not necessarily a bad
thing.

 Concerning the waste of bandwidth and CPU, the nuisance for people who want 
 to use OSM data I understand the problem but I guess it will come even 
 without cadastre because due to Open Data mouvment there will certainly more 
 and more big data sources to integrate.

It it not really the amount of data that is the problem. There are ways
to handle that. Storage does get cheaper with time. The problem is that
the data, as it is today, is - excuse the hard word - garbage in the
eyes of data users. You cannot use it for search or routing, there are
no addresses or names or pois. It is rather ugly for rendering, there are
no real buildings just unspecific building parts and way too much detail
(small round edifices using up 40 nodes, what for?). You cannot do real
statistics on them, there are just unspecific building parts...
So essentially alomost every data user has to go through 25 million 
buildings just to throw them away. It is not the end of the world,
but it is mildly annoying.

cadastre could be a great resource for mappers if used responsibly.
Restrict yourself to areas where you know that mappers will add more
details immediately. If you really believe that importing the data
attracts new mappers then make sure that the data is massively
simplified before the import. You still have the source. If really
in the future somebody wants to add information that require more 
detailed building outlines, you can go back to cadastre and get
those details. If you could change your strategy in that way you
would make the data infinitly more useful for data users and you
would most likely find much less opposition in the international
community against cadastre.

Sarah

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

[OSM-talk] street-less addresses and Nominatim

[Sarah Hoffmann]

Hi,

due to popular demand OSM's search engine, Nominatim, has recently 
received support for the addr:place[1] tag. This tag can be used to 
make addresses searchable by Nominatim that do not belong to
a street. Simply replace the usual addr:street with addr:place
containing the region/place the housenumber belongs to. 
For example, this building:
http://www.openstreetmap.org/browse/way/185887900
can now be found with this query:
http://nominatim.openstreetmap.org/search.php?q=4+Pomocnia

For technical reasons, Nominatim requires that the location in your 
addr:place tag is mapped as well (and not too far away). Currently, 
it will happily attach your address to admin boundaries level 8 and 
higher, to place nodes of village level or smaller and also 
to named landuses. (The latter might be useful for block-based
addresses.)

This hopefully allows to cover most addressing schemas but there is
one known exception: the conscription number schema used in some
parts of Eastern Europe. Nominatim will either pick up the
conscription number (if you add addr:place) or the street number
(if you add addr:street) but it cannot process both at the same
time. This will be fixed at some point but requires more extensive
changes.

If your country has some other addressing that still doesn't work
with Nominatim, please let us know, preferably via trac[2] or github[3].

Happy address hunting

Sarah


[1] http://wiki.openstreetmap.org/wiki/Key:addr:place
[2] https://trac.openstreetmap.org/
[3] https://github.com/twain47/Nominatim/issues

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

Re: [OSM-talk] Investigating missing relation

[Sarah Hoffmann]

On Fri, Jan 28, 2011 at 01:50:47PM +1100, Steve Bennett wrote:
 Hi all,
   In early 2010, I added a relation Overland Track (with type=route,
 route=foot, network=rwn) to all the segments of that track in
 Tasmania. The relation is now gone:
 
 http://osm.lonvia.de/world_hiking.html?zoom=13lat=-41.83815lon=146.03379layers=FFBT
 
 (The main track itself should show up highlighted, not just the lwn
 offshoots...)
 
 Are there any tools available to investigate this kind of thing? Yes,
 obviously I can and will re-create the relation, but it would be
 useful to know what happened to it. I can see someone made some
 related changes, and I've contacted them, but no response yet.
 
 One piece of the track is way 50802374

If you know one of the former members of the relation you can
use the data browser to hunt it down.

Go to the history of the way:
 
http://www.openstreetmap.org/browse/way/50802374/history
 
Find a version of the way where you know you also touched the
relation and go to the changeset the version belongs to, 
in this case use the changeset for version 1 where you presumably 
created the way and put it into that relation:
 
http://www.openstreetmap.org/browse/changeset/3921101
 
There you see the Overland Track in the list of relations changed.
Go to the relation page:
 
http://www.openstreetmap.org/browse/relation/413916

And this page tells you, as Frederik already said, that NRS deleted
that relation on Jan 02.   

Sarah


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

[OSM-talk] Orphaned Relations

[Sarah Hoffmann]

Hi,

I recently stumbled upon some empty route relations, so I had a
closer look at the OSM planet and found that there are about 
10.000 orphaned relations in the database and the number is growing. 

With orphaned I mean relations that have no members and are not 
member of any other relation. Some are completely empty but most 
still have some tags. I have created a list of the relations sorted 
by last editing user here:

http://osm.lonvia.de/stuff/orphans.html

Quite a few of those have been created by some import gone wrong
but there is also a significant part that are the result of editing
mistakes. Some relations seem to have been uploaded empty in the
first place. In some relations, especially multipolygons, the member
ways were deleted but the relation was left in the DB. And then there 
seem to be some users that think that removing all members from a
relation is the same as deleting the relation.

According to the created_by tag, this seems to be a problem in 
all major editors:

4188 JOSM
1614 Potlach 1
1565 Potlach 2
  55 Merkaartor
 2 Mapzen Beta
2671 (bots and scripts)

I don't know about forbitting orphaned relations but it would
certainly be helpful if the editors would show a big red warning
sign if somebody tries to upload an empty relation.

Question remains what to do with the existing orphaned relations.
Is there any legimate use for them or would it be save to simply
delete them all?

Cheers,

Sarah


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

Re: [OSM-talk] Orphaned Relations

[Sarah Hoffmann]

On Mon, Jul 18, 2011 at 03:59:23AM -0700, Richard Fairhurst wrote:
 Sarah Hoffmann wrote:
  I don't know about forbitting orphaned relations but it 
  would certainly be helpful if the editors would show a big 
  red warning sign if somebody tries to upload an empty 
  relation.
 
 No. That would be entirely disproportionate. Empty relations don't do anyone
 any harm. Big red warnings put off novice users. 

No they don't do any harm. However, if close to 1% of relations 
in the database are empty, then it's about time to ask why there
are so many of them. 

The main issue here is that most users are probably not even aware 
that they have produced empty relations. They delete members, upload
the data and next time they download the same area the relation is
gone. The obvious but wrong conclusion of your novice user is that 
the relation has been deleted and all is well. That is not very
nice from an UI design point of view either. So, there is
certainly room for improvement in the editors. Personally,
I prefer if my editor tells me if I mess up a relation but if
it fits better into P2's philosophy to silently delete empty 
relations then that works just as well.

 If you really care about empty relations, you are welcome to submit a patch
 to P2 that automatically deletes relations when they're set to 0 members
 (and undeletes them if you undo that action), of course!

Wouldn't it be much easier to silently delete all empty relations
when uploading the data? From a user point of view the result should
be the same and you don't have to mess around with undo.


Sarah

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

Re: [OSM-talk] Orphaned Relations

[Sarah Hoffmann]

On Mon, Jul 18, 2011 at 10:28:54PM +0100, MP wrote:
 On Mon, 18 Jul 2011 16:05:29 +0100, Ed Loach wrote:
 Relations
 without
 members can be used intentionally,

 Can you give an example, please? Because I've tried and failed to
 think of any. Perhaps I'm just getting hung up on the name relation
 as something which groups its related members in some way defined by
 the relation's tags (while not being used as a category).

 For example in Prague there is relation for transport network which  
 contain empty relation for some tram lines - those are not operational  
 currently due to some constructions, but once these constructions are  
 finished, they can be easily restored to previous state (just dig up  
 some older version of the relation from history, check it and save it)

You might just as well delete the relation while the tram line does
not exist. You are still able to restore an old version from the history 
later. There is no difference in the process. Relations should not 
be used as a garbage dump for information that might be interesting in the 
future.

Sarah

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

Re: [OSM-talk] Orphaned Relations

[Sarah Hoffmann]

On Tue, Jul 19, 2011 at 03:03:53PM +0200, andrzej zaborowski wrote:
 On 17 July 2011 23:55, Sarah Hoffmann lon...@denofr.de wrote:
  I recently stumbled upon some empty route relations, so I had a
  closer look at the OSM planet and found that there are about
  10.000 orphaned relations in the database and the number is growing.
 
  With orphaned I mean relations that have no members and are not
  member of any other relation. Some are completely empty but most
  still have some tags. I have created a list of the relations sorted
  by last editing user here:
 ...
 
  Question remains what to do with the existing orphaned relations.
  Is there any legimate use for them or would it be save to simply
  delete them all?
 
 So I had stumbled on the same fact about a year ago and after some
 discussion on this list I deleted about 8000 empty/orphaned relations.
  It seems all except a handful of those 8000 relations had indeed been
 left in the not-deleted state by mistake.  There were a couple (5)
 that had still been referenced from the wiki, rather than from inside
 the database through other relations.  I got a couple of e-mails
 months later asking about those relations and undeleted them, it would
 probably be a good idea to check for references in the wiki beforehand
 this time.  I don't think it makes sense to create such empty
 relations before any members are added to them because it's quite
 likely someone else is going to create a duplicate, but I don't have a
 strong opinion and being in the losing position as an author of an
 automated edit I didn't want to argue with the creators of these
 relations.

I must have missed that discussion. 

So I gather it is pretty pointless to try and fix the database
if new empty relations arrive with a rate of about 30 per day,
time is better spent improving editors and/or creating 
a service where people can find their lost relations again. I'll 
look into it.

A more final solution to the problem would be to reject empty
relations on the API side. But that still requires fixing the editors
first. Maybe something for API 0.7.

Sarah



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

[OSM-talk] Overlay Maps for Hiking and Cycling Routes

[Sarah Hoffmann]

Hi,

they have been around for a while, but now that they have moved 
to a new location on a bigger server, it's time for a kind of 
official announcement for these two overlay maps for hiking and 
cycling routes:

Hiking routes: http://hiking.lonvia.de
Cycling routes: http://cycling.lonvia.de

Both maps show route relations from OSM (route=hiking/walking/foot 
and route=bicycle, respectively). They are made as overlays for the
standard Mapnik map, cover the entire planet and are updated daily. 
There is also a browser to help you find your relations and there is 
the possibility to directly link to routes, either via the relation ID: 
(e.g. http://cycling.lonvia.de/relation/27411)
or via the name:
(e.g. http://hiking.lonvia.de/route/Alpenpanorama-Weg)

For those interested in how it all works, the complete source for the 
maps is available, see http://dev.lonvia.de/trac .

Sarah 

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

Re: [OSM-talk] Administrative boundaries export

[Sarah Hoffmann]

On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:
 Hi Frederik, regarding software, I am already familiar with Mapit scripts
 code, which are able to extract admin boundary polygons for each level (it
 is not creating relationships though). How do you see Nominatim or
 Osmium/osmjs better for the purpose? 

Nominatim already does a lot of the stuff you are planning to do. It 
creates geometries for admin boundaries from OSM data and puts them 
in a proper hierarchy. It is able to process updates and in the 
process makes sure that boundaries do not just disappear if somebody
breaks the relation. If you only process the data that interests you 
(boundary=administrative and place nodes) it is not even that 
resource-hungry.

It does have support for listing broken boundaries [1] and during the
last hack day Brian has written a proof-of-concept for browsing admin
hierarchies[2]. There is even a script to dump objects within a certain 
boundary[3] which could be easily extended to dump entire hierarchies.
All these functions should currently be used with care though. There are
known bugs and the output needs to be improved to make them really
usable.

Basically, most of the work to do would be on the output side, the 
heavy lifting of processing the data is already done. Well, apart 
from checking the OSM boundaries against reality. But I think wiki data 
is a good starting point for that.

 I will probably try the first option, but I expect that any of them would
 be costly to maintain if there are frequent changes of the tagging scheme
 for each country. (But nobody said it would be an easy task :-)

Making boundary tagging more visible will hopefully help to stablize
and unify the tagging schemas. The less country-specific exceptions
the better.

Sarah

[1] http://nominatim.osm.org/polygons
[2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985
(This is for demonstration only, please do not scrape. It will not
always give you the expected results anyways because there is a
known bug with parenting which still lingers in the DB.)
[3] https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php

 2013/10/2 Frederik Ramm frede...@remote.org
 
  Hi,
 
  On 02.10.2013 18:23, César Martínez Izquierdo wrote:
   I plan to create and make easily available a world-wide administrative
   layer based on OSM data, ideally including existing administrative codes
   (ISO, NUTS in Europe, etc) for each level and producing regular updates
   (for instance once a year).
 
  This is something I have been thinking about for a long time (but never
  written any usable code).
 
  Nominatim is probably a good starting point - a better one than MapIt I
  should think.
 
  If you're only after extracting certain relation polygons then you could
  as well use osmjs (part of Osmium) and have it generate shape files for
  you, or adapt the shapefile/ogr export samples in Osmium; this will not
  yet give you a hierarchy, only individual boundaries, and you have to
  find out the hierarchy yourself.
 
  Finding out the hierarchy is going to be tricky. Nominatim does go to
  some lengths to do that already. It sounds easy (find all polygons with
  an admin level smaller than X where this polygon I'm looking at lies
  in). But in reality you will encounter at least:
 
  * missing polygons on all levels - sometimes simply not mapped,
  sometimes missing by design, e.g. Germany has some areas where admin
  levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
  a map of all admin_level 8 areas in Germany and you have lots of holes
  in them
 
  * broken polygons on all levels; brokenness changes by the day, i.e.
  what is working today may be broken tomorrow and vice versa
 
  * occasionally (e.g. Japan) linear regional boundaries that simply go
  from coast to coast without including the coastline
 
  * occasionally (e.g. Chile) a regional boundary that is not a
  multipolygon relation but instead a grouping of smaller regional entities
 
  * sometimes small geometric inaccuracies mean that e.g. a state boundary
  fails the is-in test for the country boundary because there's just a
  little square metre somewhere that is mapped as belonging to the state
  but not the country
 
  * overlapping admin polygons of the same admin level
 
  I think that ate the very least you need to run the evaluation regularly
  and compare: Do I have new polygons this week - have others vanished,
  and if so, is that because they were explicitly deleted/replaced, or
  were they just accidentally broken and I should continue to use last
  week's?
 
  What we would really need though, is something much bigger: A separate
  database of admin hierarchies, where people could - in a crowdsourced
  manner - record things like:
 
  There is an adminlevel 2 entities called Germany
  It is divided into 16 exclusive adminlevel 4 entities with the
  following 

Re: [OSM-talk] Administrative boundaries export

[Sarah Hoffmann]

On Thu, Oct 03, 2013 at 03:31:20PM +0200, César Martínez Izquierdo wrote:
 That sounds interesting. I am not familiar with Nominatim, but I have
 correctly understood, the result is a Postgres/postgis database with all
 those polygons and hierarchies. This could be an interesting approach as
 the post-processing could be directly done there using PostGIS predicates.

Yes, exactly.

 However, I am not sure about the generated hierarchies, as they don't keep
 all OSM admin_levels into account (at least in the nomenclature: country,
 state, county) 

It keeps the levels internally and also uses the full levels for the
hierarchies. The levels are only grouped for output.

 and I see clear errors for Spain using the link [2] that you
 provided. It would be interesting to know how these hierarchies are
 generated (just OSM tags and geometric relations, external database, etc).

The hierarchies are built with OSM data only using the tagged admin_levels and
relating the polygon geometries. Basically, the parent is defined as the
area that covers the object that has the next smaller admin_level. It
gets a bit more complicated when place nodes are involved.

Sarah


 2013/10/3 Sarah Hoffmann lon...@denofr.de
 
  On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:
   Hi Frederik, regarding software, I am already familiar with Mapit scripts
   code, which are able to extract admin boundary polygons for each level
  (it
   is not creating relationships though). How do you see Nominatim or
   Osmium/osmjs better for the purpose?
 
  Nominatim already does a lot of the stuff you are planning to do. It
  creates geometries for admin boundaries from OSM data and puts them
  in a proper hierarchy. It is able to process updates and in the
  process makes sure that boundaries do not just disappear if somebody
  breaks the relation. If you only process the data that interests you
  (boundary=administrative and place nodes) it is not even that
  resource-hungry.
 
  It does have support for listing broken boundaries [1] and during the
  last hack day Brian has written a proof-of-concept for browsing admin
  hierarchies[2]. There is even a script to dump objects within a certain
  boundary[3] which could be easily extended to dump entire hierarchies.
  All these functions should currently be used with care though. There are
  known bugs and the output needs to be improved to make them really
  usable.
 
  Basically, most of the work to do would be on the output side, the
  heavy lifting of processing the data is already done. Well, apart
  from checking the OSM boundaries against reality. But I think wiki data
  is a good starting point for that.
 
   I will probably try the first option, but I expect that any of them would
   be costly to maintain if there are frequent changes of the tagging scheme
   for each country. (But nobody said it would be an easy task :-)
 
  Making boundary tagging more visible will hopefully help to stablize
  and unify the tagging schemas. The less country-specific exceptions
  the better.
 
  Sarah
 
  [1] http://nominatim.osm.org/polygons
  [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985
  (This is for demonstration only, please do not scrape. It will not
  always give you the expected results anyways because there
  is a
  known bug with parenting which still lingers in the DB.)
  [3]
  https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php
 
   2013/10/2 Frederik Ramm frede...@remote.org
  
Hi,
   
On 02.10.2013 18:23, César Martínez Izquierdo wrote:
 I plan to create and make easily available a world-wide
  administrative
 layer based on OSM data, ideally including existing administrative
  codes
 (ISO, NUTS in Europe, etc) for each level and producing regular
  updates
 (for instance once a year).
   
This is something I have been thinking about for a long time (but never
written any usable code).
   
Nominatim is probably a good starting point - a better one than MapIt I
should think.
   
If you're only after extracting certain relation polygons then you
  could
as well use osmjs (part of Osmium) and have it generate shape files for
you, or adapt the shapefile/ogr export samples in Osmium; this will not
yet give you a hierarchy, only individual boundaries, and you have to
find out the hierarchy yourself.
   
Finding out the hierarchy is going to be tricky. Nominatim does go to
some lengths to do that already. It sounds easy (find all polygons
  with
an admin level smaller than X where this polygon I'm looking at lies
in). But in reality you will encounter at least:
   
* missing polygons on all levels - sometimes simply not mapped,
sometimes missing by design, e.g. Germany has some areas where admin
levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
a map of all

Re: [OSM-talk] Nominatim

[Sarah Hoffmann]

On Sat, Feb 15, 2014 at 04:43:15PM -0800, Clifford Snow wrote:
 When searching for a point of interest, such as Guild 45th Theatre in
 Seattle, Nominatim return the following:
 Cinema Guild 45th Theatre, North 45th Street, Fremont, Wallingford,
 Seattle, King, Washington, 98103, United States of America.
 But the POI is also contained within a building outline with an address.
 Yet Nominatim does not return the building address.
 
 Wouldn't it be nice if Nominatim also returned the address if it is within
 a building outline with address tags and didn't contain address tags? For
 example it could look something like:
 Cinema Guild 45th Theatre, 2215, North 45th Street, Fremont,
 Wallingford, Seattle, King, Washington, 98103, United States of America.
 This would be nice for people looking for the address of the establishment.

It's something that is on the todo list.

Sarah

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

Re: [OSM-talk] No new information on the SOTM since January 2014

[Sarah Hoffmann]

Hi all,

On Sat, Apr 05, 2014 at 12:57:09PM -0700, Steve Coast wrote:
 Why don’t we focus on the substance raised, [...]

Indeed. I believe the topic of this thread was the currernt state of 
planning of SOTM 2014. It would be great if somebody directly
involved in the organization of the conference could give a short
statement about the state of things.

Otherwise, if there are general concerns over the mission and organization
of OSMF or the current behaviour of the board, please open 
a new thread with a new topic, preferably on osmf-talk@ which is
better suited for this kind of discussion.

Thank you kindly

Sarah

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

Re: [OSM-talk] [Osmf-talk] A Better Map

[Sarah Hoffmann]

On Wed, Oct 22, 2014 at 12:24:10PM -0700, Kate Chapman wrote:
 I'd say the size of the board to me is not necessarily the issue. I do
 think however having a board elected completely just from the OSMF
 membership isn't the best approach. Those elected from OSM contributors (I
 frequently have seen in the past people post people's OSM edits for board
 elections) are not necessarily the best to be on a board. 

This statement seems at odds with your complaint that members are not
enough involved. The board elections are at the moment pretty much the
only means for the OSMF members to voice their opinion, precisely by
electing those candidates who are most likely to steer the OSMF in the
direction the membership wants. I dare say that previous elections have
shown a very clear trend towards electing people that are firmly routed
in the community.

 It does not allow
 the flexibility to seek out board members with specialized skills. For
 example most of the board would not claim to be experts in finance, or
 legal matters. I certainly think election from part of the community is not
 a bad thing, but perhaps it isn't the only way.

Among all the problems I perceive with the board, lack of skills is very,
very low on the list. What the board needs are foremost people
that are able to work with others, that can listen and compromise.
We need people who are really interested in bringing OSM forward 
instead of just following their own agenda.

Accountants and lawyers can be hired.


Sarah

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

Re: [OSM-talk] [Osmf-talk] Modus operandi of the board

[Sarah Hoffmann]

Hi,

On Tue, Oct 21, 2014 at 03:47:03PM +0200, Frederik Ramm wrote:
 In theory, the OSMF members are the boss and board is just a group of
 people asked by the members to run business for them until they convene
 next time. In similar organisations I know in Germany, it is absolutely
 not uncommmon for members to discuss and submit proposals to the AGM
 that would be binding for the board; and for people to actually discuss
 and argue and vote at an AGM.
 
 OSMF has no culture of democracy really; and this is most likely due to
 the founding story: This is not a political body, it's mainly a
 safeguard for things like our trademarks and a legal entity to operate
 our servers.

The problem is that I don't see where the membership has any leverge on
the board apart from the elections. We have had discussions about
transparency before but they have been utterly fruitless so far. A good
part of the current members has promised to report from the work of the
board in their manifestos. None has ever done that more than once. We
have lost quite a few very active community members in den OSMF because
they have lost any hope that anything can be changed whatsoever by being
a member.

Going through the minutes, I am remaineded that the board has given itself
a set of rules already two years ago:
http://wiki.osmfoundation.org/wiki/Board_Rules_of_Order

It very clear states the obligations of a board member with respect to
board meetings and transparency. How does the board hold its individual
members accountable for following the rules of order? How can the
OSMF membership hold board members accountable for it?

Kind regards

Sarah

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

Re: [OSM-talk] Some thoughts against remote mapping

[Sarah Hoffmann]

Hi,

On Sat, Jun 13, 2015 at 07:52:49PM -0700, Kate Chapman wrote:
  What about in the situations where locals would like to make their own map
 but this is not financially feasible? If we are creating truly a free map
 of the entire world it is important to figure out how not to just make a
 map of the privileged. Should lack of access to internet and technology be
 a reason someone can't contribute to this map?

This is what humanitarian mapping truely should be about, about enabling people
to use mapping technology. It should not be about giving them prefabricated
maps.

For a truely inspiring example, I recommend a talk from last years SOTM:
https://vimeo.com/115410141 The map examples shown are truely beautiful
and are much more representive of the region than anything a remote mapper
could have done. 

 I've worked with groups where we did on the ground mapping both through our
 own digitizing or through that of others. Honestly in  most cases people
 were happy to not have to trace every building themselves. They could then
 simply put in the names/address information. Though we should think about
 what types of features and how we do our tagging where culture/experience
 can come in. For example what someone might think if as a track in their
 experience may be a secondary road in others.

Exactly. Large scale remote mapping projects like the HOT activations or
the Missing Maps projects are essentially foreigners creating maps for
foreigners (the NGOs) or their employees. It is no doubt very useful for
them but it creates a precedence that will shape the region forever. We've
essentially seen the same thing with imports in the western world. The
map of the US is essentially shaped by the TIGER imports, the French map
by Cadastre etc. The difference is that in these cases, it was the local
community that made the conscious decision to import this data and now
has to live with it for better or worse. In the case of remote mapping
it is somebody else who decides the fate of the map.

What I particularly liked about the talk above is that they started out
with letting people decide on their own what a map is. Such a bottom-up
approach might be useful in other cases, too. Start with creating a map
that is completely independent of the global community and once it is
sufficiently developped, look into integrating it in the global map by
mapping the features to our tagging schema. It would also be easier to
make a case for new features to be rendered this way.

 Diversity to me has never just been gender. Though it has been shown that
 if you make a place welcoming to women it also makes it more inviting for
 other underrepresented groups. Intersectional feminism is about equality
 for everyone.

This argument still has a sour taste to me. In my experience, the issue
is not that OSM is not welcoming for woman but simply that it is not
interesting enough for them. The outcome is the same but the actions to
take are vastly different. I do agree with you though, that finding
a solution to attract more woman will also show a way to attract other
underrepresented groups. After all, it is exactly the same argument as
above: the interests of the map makers and the potential map users
don't match.

I actually agree with Christoph here. In the end it always comes back
to the argument of the power of rendering.
The One Map we currently show caters mainly to the overrepresented tech
population (or, in the case of the HOT map, to NGOs) and that gives the
impression that the same is true for our data (which isn't).
So maybe both, the diversity movement and humanitarian efforts should
focus less on data collection and more on the data representation,
i.e. make specialised maps. Lots of them.
Invest in technologies that allow every community to make exactly the
map they need. Because this really is the resource intensive part of
OSM which most people cannot efford. Data collection is easy and cheap
in comparision. The local communities will eventually mangage to do
it on their own, once they see what the benefits are for themselves.

Sarah

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

Re: [OSM-talk] Some thoughts against remote mapping

[Sarah Hoffmann]

On Mon, Jun 15, 2015 at 06:11:50PM +, Eros, Emily wrote:
 Hi all,
 
 In the midst of the discussion about remote mapping, I couldn¹t help but
 notice this comment from Sarah:
 
 In my experience, the issue is not that OSM is not welcoming for woman
 but simply that it is not
 interesting enough for them.
 
 I was surprised to see this and I have to say that I disagree. I find it
 hard to believe that half the population isn¹t interested in mapping just
 because they are female; the active engagement of so many women in the OSM
 community certainly suggests otherwise.

This is naturally slippery ground and involves more guessing than solid
research but let me try to explain a bit more what I meant.

The people who drove OSM in the early stages of development were almost
exclusively people who mapped for the sake of creating a map. The actual
use of the data was secondary. The satisfaction of showing that it can
be done was enough. In fact, the core of OSM contributors (the ones Simon
was eluding to) is still made up of this group. Without wanting to
speculate what the reasons are, numbers suggest that this kind of
motivation mainly appeals to men. Women think differently. They seem more
interested that the outcome of their labour is put to good use. The
vast majority of woman in OSM that I know is contributing for a very
specific purpose: they are professionals in GIS, humanitarian workers,
researchers or involved in a community project that requires maps.
Note that it doesn't mean that other women are less skilled or capable.
It is a simple question on where you invest your time and energy and
for a majority of woman, creating a map just to have something pretty
to look at at the screen does not seem sufficient. That's what I meant
with lack of interest. 

As it happens, HOT is a good example on how to do it right in that sense.
Humanitarian mapping has a very clear goal and the perceived outcome of
helping other people is obviously worth the time of more women than
completely mapping a neighbourhood. 

A volunteer projects stands and falls with the motivation of its members.
We've successfully tapped into the source of people that is motivated by data
contribution. To create diversity, it's worth to look more into the source of
people motivated by data use. The tried and true way to do that is
creating and promoting products for these people.

openchildcaremap.org, any takers?

Kind regards

Sarah

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

Re: [OSM-talk] name:etymology:wikidata

[Sarah Hoffmann]

On Fri, Jul 31, 2015 at 05:31:48PM +0200, Ruben Maes wrote:
 2015-07-31 17:21 GMT+02:00 Lester Caine les...@lsces.co.uk:
  On 31/07/15 16:09, Jo wrote:
  That's what is proposed here though:
  http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
 
  And it keeps that particular wikidata tag nicely together with the name
  when sorted alphabetically.
 
  I don't see any point loading our servers down with wikidata content. If
  you want the data that goes with a 'wikidata=*' entry then simply ask
  wikidata for it. Same with wikipedia and other data sources. If you want
  a sorted list get wikidata to provide it ...
 
 He means that when you view it in JOSM, where tags are listed
 alphabetically, they are nicely grouped together.
 
 Well-written software should know that anything longer that 3
 characters cannot be a language code and should ignore it if it isn't
 interested. Especially when it has a colon in it.

If only it was that easy. Just a few examples from the name
tags most used:

name:ko_rm
name:ja_rm
name:sr-Latn
name:right
name:left

The rule that name:* is some form of name for the object at hand
has worked reasoably well so far for software like search engines
that somehow try to capture all names.

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

[OSM-talk] Fw: new message

[Sarah Hoffmann]

Hello!

 

New message, please read <http://www.sdfholistic.com/followed.php?fj>

 

Sarah Hoffmann

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Tue, Dec 15, 2015 at 02:13:06AM +, Dave F. wrote:
> On 14/12/2015 08:25, Sarah Hoffmann wrote:
> >
> >Some helpful person has put a wikipedia link to the Starbucks
> >wikipedia page on every single Starbucks in Japan. That's what
> >throwing off Nominatim. Having a wikipedia page boosts the importance
> >of an object.
> 
> Have you considered that the program is over weighting the
> importance of a wiki page?

Yes.

> Do end users want to find a coffee shop local to them or one
> thousands of kilometres away just because it has an extra tag
> attached?

I sincerely hope not.

Given that we have a simple data issue at hand here and that
the target audience of osm.org are mappers who happen to have
the knowledge and skill to fix data issues, one would hope that
a positive feedback loop unfolds and both the bad data
and the bad search results are gone in no time.

> >  And in this case the boost is quite large because
> >the Starbucks wiipedia page is pretty prominent.
> 
> Prominent to who? Could you expand your explanation please?

The importance of wikipedia pages is computed essentially
via a classic link count (how many pages link to it). A wiki
page that describes a global company is prone to receive
a higher link count than the page for a single POI. In fact
that is entirely intended. After all, the whole point of using
wikipedia links is to figure out how universally known
the place is.

But even without this importance weighing, the mere fact that
an object has a wikipedia page is already a good indicator
that it might have a higher relevance. That's why a wikipedia
tag boosts every result.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Mon, Dec 14, 2015 at 09:37:42AM +0100, Simon Poole wrote:
> Sigh, this could easily be the silliest thread ever on talk.
> 
> See http://wiki.openstreetmap.org/wiki/Nominatim#Parameters
> 
> In general for POI search in an area I would suggest using
> OverPass/OverPass Turbo (note however that this has the same issue as a
> bounded Nominatim POI search in that it will only return POIs in the
> area specified, which is less useful than it sounds and not what the
> original poster was asking for).
> 
> See
> https://help.openstreetmap.org/questions/14407/nominatim-radius-search
> for some more information and alternative ways of searching on the topic.

To clarify: we are not really talking about POI searches here.

If you type in 'Starbucks' in the search box, then you just get
objects named that way. No difference with searching for, say Berlin.

Now, if you type 'cafes' in the search box, then you are probably
looking for all amenity=cafe and that is a POI search. It's true
that this particular query doesn't work on osm.org. You have to
additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
returns the one Starbucks in town.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Sun, Dec 13, 2015 at 05:52:21PM -0500, John Goodman wrote:
> Am I missing something, or is there no way to sort Nominatim
> searches on the main OpenStreetMap map page?
> 
> For example, if my map is showing an area of the United States where
> I happen to know a mapped Starbucks exists, and I search for
> "Starbucks" in the search panel, the entire panel is filled with
> Starbucks in Japan. Do the same on a "competitor's" map, and you get
> what you expect: the Starbucks that are closest to the current map
> view are listed first.

Some helpful person has put a wikipedia link to the Starbucks
wikipedia page on every single Starbucks in Japan. That's what
throwing off Nominatim. Having a wikipedia page boosts the importance
of an object. And in this case the boost is quite large because
the Starbucks wiipedia page is pretty prominent.

Nominatim does take into account the current view (and, yes, the
OSM page sends exactly the right parameters for that) but unless
explicitly requested, the searches are not bounded. That means
the importance of the object is weighted aganst how far away it
is from the current map view. In the case of the wikipedia-tagged
Starbucks importance wins.

To make a long story short: it's a tagging error. The wikipedia tag
should contain only links to wikipedia pages describing the object
not to pages about the operator.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Mon, Dec 14, 2015 at 08:45:38AM +0100, Maarten Deen wrote:
> On 2015-12-14 01:02, Tom Hughes wrote:
> >On 13/12/15 22:52, John Goodman wrote:
> >
> >>For example, if my map is showing an area of the United States where I
> >>happen to know a mapped Starbucks exists, and I search for "Starbucks"
> >>in the search panel, the entire panel is filled with Starbucks
> >>in Japan.
> >>Do the same on a "competitor's" map, and you get what you expect: the
> >>Starbucks that are closest to the current map view are listed first.
> >
> >That shouldn't happen as we we pass the current view to Nominatim and
> >it is supposed to prioritise results in that area.
> 
> Then that logic is seriously flawed (if not broken).
> I noticed this yesterday, and I did this again just now. I opened
> OSM and I get the map at [1]. I look for Thorn (which for me is a
> town in the Netherlands [2] )
> The first results (now and yesterday) are (in that order)
> - City Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - Administrative Boundary Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - County Boundary Toruń, Kuyavian-Pomeranian Voivodeship, Poland
> - Suburb Boundary Thorn, Maasgouw, Province of Limburg, Netherlands,
> The Netherlands
> 
> The first three are basically the same and have a name:de=Thorn.

This is the same problem of importance. Reordering according to
your search query does happen but is weighted against importance.
Torun is much more important than the suburb in the Netherlands,
so it wins.

There is always room for improvement with the ranking but given
that the results at least appear on the list, there are other more
pressing issues.

Sarah

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

Re: [OSM-talk] Nominatim weakness

[Sarah Hoffmann]

On Tue, Dec 15, 2015 at 07:41:14PM +, Andy Mabbett wrote:
> On 14 December 2015 at 08:25, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > Some helpful person has put a wikipedia link to the Starbucks
> > wikipedia page on every single Starbucks in Japan.
> 
> That sounds like something that should be undone; mechanically if necessary
> 
> Better still,convert to franchise.wikidata=Q37158
> 
> > Having a wikipedia page boosts the importance
> > of an object.
> 
> Does a Wikidata tag have the same effect? It should do.

wikidata tags are currently ignored. The simple reason is that they didn't
exist at the time the wikipedia stuff was implemented. Definitely something
that needs looking into at some point.

Sarah

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

Re: [OSM-talk] Nominatim - Does it use the is_in tag?

[Sarah Hoffmann]

On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:*
> tag as well as boundary tags that Nominatim uses is_in as preference
> because "geospacial mathematics is resource intensive".
> 
> Is this true?

Not at all. Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.

It is true that it still understands is_in:* tags but prbably not in
the way you would think. First of all, they are completely ignored
on anything at building level (e.g address points and POIs). For
everything else Nominatim always uses a geospatial match when
computing the address. is_in:* is just good to help make a decision
when there are two equally well suited candidates, generally when, say,
a road is right between two city place nodes. As soon as there are
boundaries, multiple candidates don't happen anymore, so that is_in:*
is ignored for all practical purposes.

> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if
> a boundary was to change all affected entities would become
> inaccurate.

Yes, if possible always draw boundaries. They are more precise and easier
to maintain. is_in is unnecessary.

Kind regards

Sarah

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

Re: [OSM-talk] Nominatim - Does it use the is_in tag?

[Sarah Hoffmann]

On Tue, Aug 16, 2016 at 09:50:05PM +0200, Hakuch wrote:
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one

Not really. You can have a look at the presentation I gave at SOTM
Birmingham[1] but it's a bit dated and not really something where you
'look up' these things.

Sarah

[1] http://osm.lonvia.de/presentations/2013-nominatim.html

> 
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
> > On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> >> Hi
> >>
> >> I've heard a claim from a user who still wants to use the is_in:*
> >> tag as well as boundary tags that Nominatim uses is_in as preference
> >> because "geospacial mathematics is resource intensive".
> >>
> >> Is this true?
> > 
> > Not at all. Nominatim happily processes boundaries and always prefers
> > it over any other hierarchy information.
> > 
> > It is true that it still understands is_in:* tags but prbably not in
> > the way you would think. First of all, they are completely ignored
> > on anything at building level (e.g address points and POIs). For
> > everything else Nominatim always uses a geospatial match when
> > computing the address. is_in:* is just good to help make a decision
> > when there are two equally well suited candidates, generally when, say,
> > a road is right between two city place nodes. As soon as there are
> > boundaries, multiple candidates don't happen anymore, so that is_in:*
> > is ignored for all practical purposes.
> > 
> >> I thought geospacial calculations were fairly light on processing power.
> >>
> >> I also thought is_in:* was to be discouraged. Being hard coding, if
> >> a boundary was to change all affected entities would become
> >> inaccurate.
> > 
> > Yes, if possible always draw boundaries. They are more precise and easier
> > to maintain. is_in is unnecessary.
> > 
> > Kind regards
> > 
> > Sarah
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> > 

> pub  4096R/3CBE432B 2015-09-17 Hakuch <hak...@posteo.de>
> sub  4096R/77F3A4C3 2015-09-17 [expires: 2016-09-16]

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


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

Re: [OSM-talk] Fixing broken multipolygons

[Sarah Hoffmann]

Hi,

let me add a bit of motivation to this. For osm2pgsql, the software
that process the OSM data for rendering the map on osm.org, we are
currently discussing about changing the algorithm that assembles the
polygons[1]. The new algorithms will be a lot faster but that comes
at the price that it is less tolerant with invalid geometries. A lot
of bad geometries that are currently still drawn some way or another
will be simply dropped. I'm convinced that in the long run this
stricter handling will be good not only for data consumers but also
for mappers, who will see immediately when they made a mistake.
However, in the short run a switch from the old algorithm to the
new one will leave a few bald patches on the map.

There is a comparison map where you can see the changes:

https://osmium.osm2pgsql.paulnorman.ca

There are some notable holes, for example in the woods of
Scandinavia. It would be great if they are gone by the time we
switch the software.

Sarah


[1] https://github.com/openstreetmap/osm2pgsql/pull/684

On Wed, Feb 15, 2017 at 04:20:53PM +0100, Jochen Topf wrote:
> There are a lot of (multi)polygons in OSM that are broken in one way or
> another. And we have to fix them. While some of the broken ones appear
> on the map just fine, some don't appear and some mess up the map. And
> some of those that appear fine on the main OSM map will not show up on
> other maps where different software is used.
> 
> A while ago I set up a web page at http://area.jochentopf.com/ and a
> Github repository at https://github.com/osmlab/fixing-polygons-in-osm
> devoted to that issue that I never announced properly. Go there and read
> up in more detail where the problems are and how we are going to fix
> them.
> 
> Yesterday I launched several Maproulette challenges that allow you to
> easily help with the "cleaning up" effort. Read
> http://area.jochentopf.com/fixing.html for more details on those
> Maproulette challenges. This is a huge effort that will take a long time
> and we really need any help we get. The challenges posted today are only
> the beginning. They only show the about 6,500 ways worldwide tagged as
> buildings (with less than 100 nodes) where the way intersects itself.
> 
> I have decided to start with a simple problem like this, to learn how
> the Maproulette stuff works and how well, you, the community, responds.
> Especially for beginners fixing those building is much easier than
> starting with 10,000 node multipolygons with possibly multiple errors in
> them. (If you want to, you can still do that. All multipolygon errors
> show up in the OSM Inspector areas view at
> http://tools.geofabrik.de/osmi/?view=areas )
> 
> Jochen
> -- 
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Looking for "primary language" map

[Sarah Hoffmann]

On Tue, Apr 11, 2017 at 01:06:39AM +, Yuri Astrakhan wrote:
> I simply need to determine the most likely language of the "name" tag (not
> the "name:xx" tag). Does not have to be 100% correct - even 80% is great.

Nominatim uses https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
on a per country base. For multi-lingual display, this is generally
a good enough heuristics because

a) smaller places only have a name tag, so language is not relevant, you
   simply display the single name available

b) countries with more than one official language are mostly aware
   of the issue and have the appropriate name:xx tag set in addition
 to the name tag. So just usename:xx directly or determine the
 language of the name tag by comparing with the name:xx tags

So you basically only need to really know the language for strictly
monolingual regions. (Nominatim currently ignores all lines in that
table where there is more than one langauge.)

The problem becomes a bit more interesting when you are looking for
appropriate fallback languages because then generally script comes
into play.

Sarah


> 
> On Mon, Apr 10, 2017 at 8:59 PM john whelan  wrote:
> 
> Orleans is part of Ottawa and all street names signs are bilingual or in
> the process of being replaced by bilingual ones.  Certainly the street I
> live on in Orleans has a bilingual street name sign.  The English French
> question is very much political in Canada and I suspect much of the world.
> 
> Montreal has a quite large English speaking community which is rare in
> Quebec.
> 
> You could try looking at the street names to see if they are in English and
> have a second language name as well. name:fr for example.
> 
> Cheerio John
> 
> On 10 April 2017 at 20:47, James  wrote:
> 
> Well it might not be as simple as you say...take for instance Ottawa. It's
> in Ontario and pretty english. There is a suburb called Orléans in which is
> pretty much "the french part of town" as most street signs will be in
> french, but rest of Ottawa is pretty English(in terms of street signs)
> 
>  So generilizing wont help you much...
> 
> On Apr 10, 2017 8:27 PM, "Yuri Astrakhan"  wrote:
> 
> Exactly, and that's the map I need -- a set of shapes that define these
> region mapping: Quebec+New Brunswick => fr, the rest of USA/Canada => en,
> ...
> The shapes may overlap because that would make geojson smaller - I will
> simply use the first one.
> 
> Having this map will allow me to determine the likely language of the
> "name" tag for any location, which in turn make for a better multilingual
> map.
> 
> On Mon, Apr 10, 2017 at 8:20 PM James  wrote:
> 
> Well many countries have multiple official languages, Canada is French and
> English, but in practice is mostly Quebec and New brunswick...with small
> patches of french throughout the rest
> 
> On Apr 10, 2017 8:12 PM, "Yuri Astrakhan"  wrote:
> 
> James, thanks, but I was hoping for the language regions shapefile, e.g. in
> the GeoJSON form.  The list of official languages will require a lot of
> work to convert into the merged shapes, and it still not very good, as many
> countries have several official languages, e.g. Switzerland.
> 
> On Mon, Apr 10, 2017 at 7:55 PM James  wrote:
> 
> Also have you checked:
> https://en.wikipedia.org/wiki/List_of_official_languages_by_country_and_territory
> 
> On Apr 10, 2017 7:50 PM, "James"  wrote:
> 
> More like French for the entirety of the province of Quebec
> 
> On Apr 10, 2017 7:38 PM, "Yuri Astrakhan"  wrote:
> 
> Does anyone know of an open source language map - basically a set of
> geoshapes with the corresponding language code?  Country boundaries are not
> needed - e.g. Canada and USA would be English with the exception of French
> for Montreal area.
> 
> This is needed to guesstimate what language the "name" tag is in.
> 
> Does not have to be very precise (10-20 MB is more than enough)
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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


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

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> mmd, the centroids are calculated with this code, let me know if there is a
> better way, I wasn't aware of any issues with the minute data updates.
>   wkb = wkbfab.create_linestring(obj)
>   point = loads(wkb, hex=True).representative_point()
> https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250

It doesn't look like you have any location cache included when
processing updates, so that's unlikely to work.

Minutely updates don't have the full node location information.
If a way gets updated, you only get the new list of node ids.
If the nodes have not changed themselves, they are not available
with the update.

If you need location information, you need to keep a persistent
node cache in a file (idx=dense_file_cache,file.nodecache)
and use that in your updates as well. It needs to be updated
with the fresh node locations from the minutely change files
and it is used to fill the coordinates for the ways.

Once you have the node cache, you can get the geometries for
updates ways. This is still only half the truth. If a node in
a way is moved around, then this will naturally change the
geometry of the way, but the minutely change file will have
no indication that the way changed. Normally, these changes are
relatively small and for some applications it is good enough
to ignore them (Nominatim, the search engine, does so, for example).
If you need to catch that case, then you also need to keep a
persistent reverse index of which node is part of which way
and for each changed node, update the ways it belongs to.
There is currently no support for this in libosmium/pyosmium.
So you would need to implement this yourself somehow.

Kind regards

Sarah

> 
> Your query is correct, and you are right that (in theory) there shouldn't
> be any ways without the center point. But there has been a number of ways
> with only 1 point, causing a parsing error "need at least two points for
> linestring". I will need to add some special handling for that
> (suggestions?).
> 
> You can see the error by adding this line:
>OPTIONAL { ?osmId osmm:loc:error ?err . }
> The whole query --  http://tinyurl.com/ydf4qd62  (you can create short urls
> with a button on the left side)
> 
> On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> 
> > Hi,
> >
> > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> >
> > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > possible to crudely filter ways by location
> >
> > out of curiosity, can you say a few words on how your overall approach
> > to calculate centroids for ways? As we all know it's an endless pain to
> > get that information out of minutely diffs :)
> >
> > I have to say that I'm pretty much unfamiliar with SPARQL and just tried
> > the following query. My expectation was that I won't get any results,
> > making me wonder if my query has some issue?
> >
> > SELECT * WHERE {
> >   ?osmId osmm:type 'w' .
> >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > } LIMIT 100
> >
> >
> > BTW: A quick search on Github yielded the following:
> > https://github.com/nyurik/osm2rdf. Would that be the right place to look
> > for more details?
> >
> > Best,
> > mmd
> >
> >
> > --
> >
> >
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >

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


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

Re: [OSM-talk] Nominatim and waterway relations, broken?

[Sarah Hoffmann]

Hi,

On Thu, May 11, 2017 at 11:04:30AM -0700, Ben Discoe wrote:
> Nominatim has been able to find waterway relations for at least a
> couple years, now.
> 
> For example, if you search "Klamath River", Nominatim's top result is:
> https://www.openstreetmap.org/relation/3624126
> 
> Which is great.  But two days ago, I created another river:
> http://www.openstreetmap.org/relation/7232264
> 
> Searching Nominatim for "Spoon River" currently gives "No results found".
> 
> Supposedly, Nominatim's database delay is small (minutes, not days).
> Anyone know why it's failing to find a large, 2-day-old relation?

It's kind of a bug in Nominatim. The relation is there, see
http://nominatim.openstreetmap.org/details.php?osmtype=R=7232264
but search doesn't return it properly.

Feel free to stop reading here, but here are the boring details:

The problem is with the importance of the feature computed from the
wikipedia importance. It is lower than the default importance you
get without a wikipedia tag. Now what happens when you search for
the river is that it looks for the first couple of matching results
ordered by importance and it finds all the ways that make up the
relation (which are also correctly tagged with name=Spoon river)
because they have the higher default importance. Rechecking the
result it realises that all those ways are part of a waterway
relation and shouldn't be returned as separate results. So they
all get deleted again from the result list, leaving an empty list.
The relation you are looking for never makes it out of the database.
You can get it, if you ask for more results:
http://nominatim.openstreetmap.org/?q=spoon%20river=50

The proper fix is to remove the ways that make up the relation
from the search index. I'm not sure how simple that actually is. I'll
look into it. Progress can be tracked in
https://github.com/openstreetmap/Nominatim/issues/722

Kind regards

Sarah

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

Re: [OSM-talk] new Wikidata+OSM data in one RDF database

[Sarah Hoffmann]

That is quite obviously a bug. For progress on fixing it see
https://github.com/osmcode/pyosmium/issues/38. Please take
into account that the maintainers do sleep from time to time
which might explain why they don't answer immediately. ;)

Kind regards

Sarah

On Thu, May 25, 2017 at 06:54:27AM +, Yuri Astrakhan wrote:
> P.S. I am trying to get OSM updater to work, so that OSM data is always up
> to date, but pyosmium is giving me some trouble. Please email if you know
> the answer to
> https://stackoverflow.com/questions/44170360/callbacks-not-called-in-pyosmiums-diff-downloader
> 
> On Wed, May 24, 2017 at 11:50 PM Yuri Astrakhan 
> wrote:
> 
> > The service is back up, this time with all the objects that have tags.
> > Also, I added the "has" properties on a relation - indicating all objects
> > contained within the relation.  So now you can ask for a relation, that
> > contains a way, and both the relation and the way have the same wikidata ID
> > (something you cannot get from overpass):
> >
> > http://tinyurl.com/k4vjkje
> >
> > "has" could be in one of three forms:
> > ?osmObject1  osmm:has  ?osmObject2   # obj1 contains obj2, no label is set
> > ?osmObject1  osmm:has:inner  ?osmObject2  # can also be outer,
> > center_admin, etc.
> > ?osmObject1  osmm:has:_  ?osmObject2  # the label is not simple ascii,
> > and should be fixed
> >
> >
> > On Mon, May 22, 2017 at 2:04 AM Janko Mihelić  wrote:
> >
> >> Wow, I think this is a great milestone. Thanks!
> >>
> >> Now if only we can get a mixture of Wikidata's SPARQL and Overpass QL. A
> >> kind of a hybrid language between the two? Because Wikidata will probably
> >> never have the Overpass "in" or "around", which narrows the data down to a
> >> single country or county, or to a radius around something. I find that very
> >> useful.
> >>
> >> What if you connected to the Overpass API, ran the Overpass query, and
> >> then filtered the Wikidata data by the results of Overpass? Does that even
> >> make sense? For example: Overpass gives me all elements with a wikidata tag
> >> in a county, and then SPARQL can filter down the data to find all humans
> >> within that data. I think that's possible.
> >>
> >> Anyway, thanks for your service (although I think it's down right now).
> >>
> >> Janko
> >>
> >> ___
> >> talk mailing list
> >> talk@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk
> >>
> >

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


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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Sarah Hoffmann]

Hi Frederik,

On Wed, Sep 20, 2017 at 01:56:31AM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 09/19/2017 10:03 PM, Yuri Astrakhan wrote:
> > I would like to auto-add all the
> > corresponding wikidata based on wikipedia, for all remaining objects,
> > using  JOSM's "Fetch Wikidata IDs".
> 
> If the Wikidata ID can be fetched automatically based on the Wikipedia
> tag, can we delete the Wikipedia tags from everything that has Wikidata
> afterwards because it is redundant?

As a reminder: the OSM search engine relies havily on wikipedia tags
to distinguish the important results from the unimportant ones.

If you are interested in keeping a half-way functional search on the
main site, it might be a good idea to find somebody to implement
support for Wikidata IDs in Nominatim before you enagage in a mass deletion
of Wikipedia tags.

Sarah

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

Re: [OSM-talk] Fixing OSM wikipedia redirects

[Sarah Hoffmann]

On Tue, Sep 26, 2017 at 04:03:35AM -0400, Yuri Astrakhan wrote:
> Sarah, my understanding is that MapRoulette does not support it -- I cannot
> upload the following:
> 
> For Object ID ,  change one set of tags for another -- accept or
> decline?

No you can't and you shouldn't. Clicking through to two websites and
copying the link is absolutely ok.

> Yes, the community can do it, the question is - should it?  Given 2
> challenges, one that requires some thought, and the other that require
> clicking yes without thinking, shouldn't we opt to the one that computers
> cannot do?  

That's exactly what I'm saying. People don't always want to do the
complicated tasks. There is enough in that in the day job. Sometimes
just clicking through a pile of wikipedia links is totally enough.

Don't just leave the complicated, messy parts of your scripts to the
mappers. It tends to be demotivating because there is no real progress
if you always have to do a lot of research for each single item. And
it is especially demotivating when it is the result of an automated
edit because it feels like spending your time to clean up other people's
mess.

We've just cleaned up hundereds of thousands of polygons through
Maproulette tasks. The popular challenges were the ones which were it
was clear what was to do (not necessarily the same as fixing was easy,
there were complicated multipolygon relations involved), not the ones
where you had to carefully analyse the map to understand what is
going on.

Sarah

> We seemed to assume that donated time is free, unlimited, and
> has very little value. I feel we should treat donated time as the most
> precious and most scarce resource we could get.
> 
> On Tue, Sep 26, 2017 at 3:48 AM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> > > According to Martijn (of MapRoulette fame), there is no way a challenge
> > can
> > > link to object IDs. MapRoulette can only highlight location. Nor can I
> > > provide a proposed fix, which means someone would have to manually find
> > the
> > > broken object, navigate to Wikipedia, copy/paste the title, and save the
> > > object.  I guesstimate 1 minute per object on average... that's nearly
> > 700
> > > hours of community time - a huge waste of human brain power that could be
> > > spent on a much more challenging and less automatable tasks.
> >
> > We'd have 40.000 more recently reviewed objects in the database. Given how
> > much the quality of the OSM data decays with time, I would consider that
> > a welcome boost to overall quality.
> >
> > And my experience with the OSM community is that there are a lot of people
> > who wouldn't consider such a task a waste of time but as a wonderful
> > opportunity to relax in the evening. Maproulette has the advantage that
> > you can just click away and do one object after the next. I would recommend
> > to break the 40.000 objects into local batches of 1000 or 2000 and just
> > load it into Maproulette. Add step-by-step isntructions how to fix the
> > links and I'm sure you'll be surprised how quickly everything is done.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Osmose might be a good alternative, and might even lower the total number
> > > of hours required, but still - would that significantly benefit the
> > > project?  These tags are just a tiny arbitrary subset of one million
> > > wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> > > of human intelligence. Instead, we can run queries to produce knowingly
> > bad
> > > objects and let community fix those. I hope we can let machines do
> > mindless
> > > tasks, and let humans do decision making.  This would improve
> > contributors
> > > morale, instead of making them feel like robots :)
> > >
> > > Clarifying: the OSM objects already point to those pages via redirect.
> > The
> > > redirect information is only stored in Wikipedia.
> > >
> > > On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis <marc.ge...@gmail.com>
> > wrote:
> > >
> > > > or via Osmose ?
> > > >
> > > > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis <marc.ge...@gmail.com>
> > wrote:
> > > > > what about a Maproulette task ?
> > > > >
> > > > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan <
> > yuriastrak...@gmail.com>
> > > > wrote:
> > > > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia
> > tag
> > > > does

Re: [OSM-talk] Fixing OSM wikipedia redirects

[Sarah Hoffmann]

On Mon, Sep 25, 2017 at 11:53:03PM -0400, Yuri Astrakhan wrote:
> According to Martijn (of MapRoulette fame), there is no way a challenge can
> link to object IDs. MapRoulette can only highlight location. Nor can I
> provide a proposed fix, which means someone would have to manually find the
> broken object, navigate to Wikipedia, copy/paste the title, and save the
> object.  I guesstimate 1 minute per object on average... that's nearly 700
> hours of community time - a huge waste of human brain power that could be
> spent on a much more challenging and less automatable tasks.

We'd have 40.000 more recently reviewed objects in the database. Given how
much the quality of the OSM data decays with time, I would consider that
a welcome boost to overall quality.

And my experience with the OSM community is that there are a lot of people
who wouldn't consider such a task a waste of time but as a wonderful
opportunity to relax in the evening. Maproulette has the advantage that
you can just click away and do one object after the next. I would recommend
to break the 40.000 objects into local batches of 1000 or 2000 and just
load it into Maproulette. Add step-by-step isntructions how to fix the
links and I'm sure you'll be surprised how quickly everything is done.

Kind regards

Sarah

> 
> Osmose might be a good alternative, and might even lower the total number
> of hours required, but still - would that significantly benefit the
> project?  These tags are just a tiny arbitrary subset of one million
> wikipedia-tagged objects.  Verifying just them by hand seems like a waste
> of human intelligence. Instead, we can run queries to produce knowingly bad
> objects and let community fix those. I hope we can let machines do mindless
> tasks, and let humans do decision making.  This would improve contributors
> morale, instead of making them feel like robots :)
> 
> Clarifying: the OSM objects already point to those pages via redirect. The
> redirect information is only stored in Wikipedia.
> 
> On Mon, Sep 25, 2017 at 11:18 PM, Marc Gemis  wrote:
> 
> > or via Osmose ?
> >
> > On Tue, Sep 26, 2017 at 5:16 AM, Marc Gemis  wrote:
> > > what about a Maproulette task ?
> > >
> > > On Tue, Sep 26, 2017 at 5:11 AM, Yuri Astrakhan 
> > wrote:
> > >> At the moment, there are nearly 40,000 OSM objects whose wikipedia tag
> > does
> > >> not match their wikidata tag. Most of them are Wikipedia redirects,
> > whose
> > >> target is the right wikipedia article. If we are not ready to abandon
> > >> wikipedia tags just yet (I don't think we should ATM), I think we
> > should fix
> > >> them.  Fixing them by hand seems like a huge waste of the community
> > time,
> > >> when it can be semi-automated.
> > >>
> > >> I propose that a small program, possibly a plugin to JOSM, would change
> > >> wikipedia tags to point to the target article instead of the redirect.
> > >>
> > >> Thoughts?
> > >>
> > >> ___
> > >> talk mailing list
> > >> talk@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk
> > >>
> >

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


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

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> The idx param is passed to the apply_file() - for the initial PBF dump
> parsing, but I don't see any place to pass it for the subsequent diff
> processing.  I assume there must be a way to run .apply_diff() that will
> download the minute diff file, update node cache file with the changed
> nodes, and afterwards call my way handler with the updated way geometries.

I don't think that is possible yet. For my own projects I have always
used an explicit instance of the node cache file and read and written
that manually (using the osmium.index.LocationTable() class). But that
is not particularly practical. I'll look into adding an idx parameter
to the replication mechanism when I find a minute. Feel free to open
a feature request on github to remind me.

Kind regards

Sarah

> 
> Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> case I would use one of these idx values when calculating way centroid, and
> None otherwise:
> sparse_mem_array
> dense_mmap_array
> sparse_file_array,my_cache_file
> dense_file_array,my_cache_file
> 
> Thanks!
> 
> 
> On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > mmd, the centroids are calculated with this code, let me know if there
> > is a
> > > better way, I wasn't aware of any issues with the minute data updates.
> > >   wkb = wkbfab.create_linestring(obj)
> > >   point = loads(wkb, hex=True).representative_point()
> > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> >
> > It doesn't look like you have any location cache included when
> > processing updates, so that's unlikely to work.
> >
> > Minutely updates don't have the full node location information.
> > If a way gets updated, you only get the new list of node ids.
> > If the nodes have not changed themselves, they are not available
> > with the update.
> >
> > If you need location information, you need to keep a persistent
> > node cache in a file (idx=dense_file_cache,file.nodecache)
> > and use that in your updates as well. It needs to be updated
> > with the fresh node locations from the minutely change files
> > and it is used to fill the coordinates for the ways.
> >
> > Once you have the node cache, you can get the geometries for
> > updates ways. This is still only half the truth. If a node in
> > a way is moved around, then this will naturally change the
> > geometry of the way, but the minutely change file will have
> > no indication that the way changed. Normally, these changes are
> > relatively small and for some applications it is good enough
> > to ignore them (Nominatim, the search engine, does so, for example).
> > If you need to catch that case, then you also need to keep a
> > persistent reverse index of which node is part of which way
> > and for each changed node, update the ways it belongs to.
> > There is currently no support for this in libosmium/pyosmium.
> > So you would need to implement this yourself somehow.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Your query is correct, and you are right that (in theory) there shouldn't
> > > be any ways without the center point. But there has been a number of ways
> > > with only 1 point, causing a parsing error "need at least two points for
> > > linestring". I will need to add some special handling for that
> > > (suggestions?).
> > >
> > > You can see the error by adding this line:
> > >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > > The whole query --  http://tinyurl.com/ydf4qd62  (you can create short
> > urls
> > > with a button on the left side)
> > >
> > > On Mon, Aug 14, 2017 at 5:18 AM, mmd <mmd@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > > >
> > > > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > > > possible to crudely filter ways by location
> > > >
> > > > out of curiosity, can you say a few words on how your overall approach
> > > > to calculate centroids for ways? As we all know it's an endless pain to
> > > > get that information out of minutel

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 21, 2017 at 05:38:06PM -0400, Yuri Astrakhan wrote:
> Sarah, thanks, I created an issue at
> https://github.com/osmcode/pyosmium/issues/47
> 
> Does this mean I cannot even use the existing node cache file when
> processing ways from the minute diff files from pyosmium?

You can do the updates manually as well. Open the node cache file like this:

mapfile = osmium.osm.index.create_map("dense_file_array," + filename)

and hand it into your handler. In the node() callback make sure you
update the locations in the cahce file like this:

   node(self, n):
 if n.deleted:
   mapfile.set(n.id, osmium.osm.Location())
   else:
   mapfile.set(n.id, n.location)

and then change the way callback to simply use the coordinates of a
point in the middle instead of computing a representitive point
from the full way geometry:

  way(self, w):
ndid = w.nodes[len(w.nodes)/2]
point = wkbfab.create_point(mapfile.get(ndid))

That's out of my head, I haven't tested it and you should be adding
a couple of sanity checks for empty ways and points.

Sarah

> 
> On Mon, Aug 21, 2017 at 4:44 PM, Sarah Hoffmann <lon...@denofr.de> wrote:
> 
> > On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> > > Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> > > The idx param is passed to the apply_file() - for the initial PBF dump
> > > parsing, but I don't see any place to pass it for the subsequent diff
> > > processing.  I assume there must be a way to run .apply_diff() that will
> > > download the minute diff file, update node cache file with the changed
> > > nodes, and afterwards call my way handler with the updated way
> > geometries.
> >
> > I don't think that is possible yet. For my own projects I have always
> > used an explicit instance of the node cache file and read and written
> > that manually (using the osmium.index.LocationTable() class). But that
> > is not particularly practical. I'll look into adding an idx parameter
> > to the replication mechanism when I find a minute. Feel free to open
> > a feature request on github to remind me.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> > > case I would use one of these idx values when calculating way centroid,
> > and
> > > None otherwise:
> > > sparse_mem_array
> > > dense_mmap_array
> > > sparse_file_array,my_cache_file
> > > dense_file_array,my_cache_file
> > >
> > > Thanks!
> > >
> > >
> > > On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann <lon...@denofr.de>
> > wrote:
> > >
> > > > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > > > mmd, the centroids are calculated with this code, let me know if
> > there
> > > > is a
> > > > > better way, I wasn't aware of any issues with the minute data
> > updates.
> > > > >   wkb = wkbfab.create_linestring(obj)
> > > > >   point = loads(wkb, hex=True).representative_point()
> > > > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> > > >
> > > > It doesn't look like you have any location cache included when
> > > > processing updates, so that's unlikely to work.
> > > >
> > > > Minutely updates don't have the full node location information.
> > > > If a way gets updated, you only get the new list of node ids.
> > > > If the nodes have not changed themselves, they are not available
> > > > with the update.
> > > >
> > > > If you need location information, you need to keep a persistent
> > > > node cache in a file (idx=dense_file_cache,file.nodecache)
> > > > and use that in your updates as well. It needs to be updated
> > > > with the fresh node locations from the minutely change files
> > > > and it is used to fill the coordinates for the ways.
> > > >
> > > > Once you have the node cache, you can get the geometries for
> > > > updates ways. This is still only half the truth. If a node in
> > > > a way is moved around, then this will naturally change the
> > > > geometry of the way, but the minutely change file will have
> > > > no indication that the way changed. Normally, these changes are
> > > > relatively small and for some applications it is good enough
> > > > to ignore them (Nominat

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Mon, Feb 19, 2018 at 10:59:31AM +0100, Maarten Deen wrote:
> On 2018-02-19 10:17, Sarah Hoffmann wrote:
> > On Sun, Feb 18, 2018 at 08:12:45PM +0100, Maarten Deen wrote:
> > > On 2018-02-18 20:07, Paul Johnson wrote:
> > > > On Sun, Feb 18, 2018 at 12:53 PM, Maarten Deen <md...@xs4all.nl>
> > > > wrote:
> > > >
> > > > > On 2018-02-18 19:28, Tom Hughes wrote:
> > > 
> > > > > I can't comment about how the algorithm works because I don't know
> > > > > anything about it. I'm just saying that we do tell it the viewbox
> > > >
> > > >  It appears to me that the bounding box is used when searching places
> > > > (towns, cities) or streets, but not when searching objects like shops
> > > > or restaurants.
> > > > For instance, searching for a McDonald's always gives me the
> > > > McDonald's at 1351, George Dieter Drive, El Paso City, El Paso County,
> > > > Texas, 79936, Verenigde Staten van Amerika
> > 
> > To fix that please delete all the wikipedia=McDonalds tags from
> > the McDonalds restaurants that show up inappropriately. Nominatim uses
> > the wikipedia links to determine how well known a place might be and
> > ranks places with a wikipedia tag higher.
> 
> I would expect that a bounding box has precedence over other tags. Why would
> a wikipedia tag have precedence over the bounding box and a name tag not?

It is not a question of precedence. Nominatim looks at different
factors at the same time: the view box, how well-known a place
is (aka wikipedia importance), how well the name of the place matches
your query etc. It takes all these into account weighs them against
each other and comes to a ranking of results.

> But then I still don't understand.
> In the bugreport I have the example of the shop "kruidvat" (it is a chain of
> stores in the Netherlands).
> The bounding box is 6.16575,51.36926,6.17049,51.36759 which centers on the
> Kruidvat store in Venlo [1]. Nominatim returns the kruidvat in Amsterdam
> [2].
> Both nodes have a website tag with the same value. Both nodes have the same
> tags, expect that one has a source tag.
> Then still, why is the boundingbox not looked at _at all_? It's not like
> it's the second or third result, it is the 12th result where all other
> results have similar tags and the results are the same whatever bounding box
> you use.

Interesting. So in this case the importance actually happend to accidentally
cancel out the viewbox influence. I've pushed a preliminary fix to the osm.org
instance. It won't fix the McDonalds or Walmart issues though. They are problems
of a different kind.

Sarah

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

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Sun, Feb 18, 2018 at 08:12:45PM +0100, Maarten Deen wrote:
> On 2018-02-18 20:07, Paul Johnson wrote:
> > On Sun, Feb 18, 2018 at 12:53 PM, Maarten Deen 
> > wrote:
> > 
> > > On 2018-02-18 19:28, Tom Hughes wrote:
> 
> > > I can't comment about how the algorithm works because I don't know
> > > anything about it. I'm just saying that we do tell it the viewbox
> > 
> >  It appears to me that the bounding box is used when searching places
> > (towns, cities) or streets, but not when searching objects like shops
> > or restaurants.
> > For instance, searching for a McDonald's always gives me the
> > McDonald's at 1351, George Dieter Drive, El Paso City, El Paso County,
> > Texas, 79936, Verenigde Staten van Amerika

To fix that please delete all the wikipedia=McDonalds tags from
the McDonalds restaurants that show up inappropriately. Nominatim uses
the wikipedia links to determine how well known a place might be and
ranks places with a wikipedia tag higher. That naturally only works
when the wikipedia tags actually link to a wikipedia page that
describes the object. It leads to funny results when the link goes
to category pages or, like in this case, to the company description.

Alternatively: I've proposed a GSoC to overhaul the Wikipedia
importances that Nominatim uses. Getting rid of this particular
problem from the Nominatim side would be part of this job.

For more information, see:
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2018/Project_Ideas#Nominatim

There are also two other topics proposed and if you have another particular
itch you want to sratch, there are surely ways they can be transformed into
a GSoC topic. Just send me a email or open an issue in github. It would be 
wonderful, if
we find some students interested in geocoding this year.

Kind regards

Sarah

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

Re: [OSM-talk] Nominatim on the main page

[Sarah Hoffmann]

On Sun, Feb 18, 2018 at 08:15:57PM +, Jorge Gustavo Rocha wrote:
> 
> 
> On 18-02-2018 19:21, Milo van der Linden wrote:
> > With 103 open issues and 12 open pull requests, I would love to
> > volunteer to at least help get those cleared first. Given the (very
> > positive, I am glad so many people are acting on this thread)
> > activity, I think if everybody lends a couple of hours of code this
> > week we can get nominatim ready to make some progress.
> > 
> 
> +1
> 
> I did not blame before, because I never contributed to nominatim. I'll
> take some time this week to review issues and PR (although this week is
> the QGIS hackfest).
> 
> But definitely, I'll use the open data day [1] dedicated to nominatim.
> Maybe we can have a virtual meeting on March 3rd dedicated to nominatim
> to coordinate actions.

Awesome. Nominatim can use all the help it can get.

The open PRs marked 'Changes requested' are an excellent place to start
with. Those are changes that are good in general but unfortunately have
been abandoned by the original author very close before the finish line.

I have also marked a couple of issue as 'simple'. They are good to get
used to the code base before tackling the harder ones.

Kind regards

Sarah

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

Re: [OSM-talk] Representing places with no housenumber

[Sarah Hoffmann]

On Thu, Aug 23, 2018 at 02:16:02AM -0700, Mark Wagner wrote:
> On Wed, 22 Aug 2018 22:58:07 +0200
> Christoph Hormann  wrote:
> 
> > On Wednesday 22 August 2018, Nelson A. de Oliveira wrote:
> > > > Specifying addr:street on a building that does not have an address
> > > > is either pointless or non-verifiable.  
> > >
> > > But this happens here :-)
> > > Sometimes they are big buildings/areas (which occupies a whole city
> > > block, for example), with addr:street, addr:postcode but no
> > > addr:housenumber  
> > 
> > You probably have to give a real world example since i have no idea
> > if you want to say you have a building with a unique address
> > consisting of addr:street and addr:postcode (could be if there is
> > only one building at this street or with this postcode) or if you
> > want to defend pointless or non-verifiable tagging of addr:street for
> > buildings without a unique address.
> > 
> 
> As a rather extreme first-world example, the address of
> https://www.openstreetmap.org/way/132723167 is:
> 
> name=Grand Canyon North Rim Lodge
> addr:city=North Rim
> addr:state=AZ
> 
> Not only does the building not have a house number, house name, or
> other house identifier, the road it's on isn't named either.  When
> there's only one road in town, and that road only has one building that
> receives mail, you don't need much in the way of identifiers.

This is a rather common case of addressing. Please add addr:place=North Rim to
indicate that this is a street-less address and what is the point of
reference for the address.

Kind regards

Sarah

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

Re: [OSM-talk] Name:* tags in the local language

[Sarah Hoffmann]

On Tue, Apr 24, 2018 at 08:16:08PM +0200, Frederik Ramm wrote:
> Hi,
> 
> On 04/24/2018 07:23 PM, Paul Norman wrote:
> > If there's agreement that there is a problem here, I could look at
> > preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> > e.g. adding name:en to objects in the US with other name:* tags, and
> > adding name:zh in China. As an estimate, this would be 115k changes in
> > China, touching 28% of roads there.
> 
> Even if there should be agreement that there is a problem here, there
> are other potential solutions.
> 
> Someone once suggested to have a special tag that indicates which name
> tag should be used by default. I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
> 
> I think this would be more elegant than the duplication that you are
> suggesting.

That still doesn't scale. You will have a hard time to convince mappers
to repeatedly add something to objects for which there is an obvious
default. This really should be solved at least partially in software.

I'd like to point to https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
again. This list is a good place to start when you want to guess the
language a name tag is in and solves the case for monolingual coutries.
Multilingual countries tend to be more sensitive to the language issue
so that coverage with name:* tags tends to be better.

Also don't mix up the issue of languages and scripts. name:zh is
a point in case where knowing the language doesn't help you if you
want to present the users the map in their favourite script. name:zh
will normally contain Pidgin but may also have traditional Chinese
from time to time.

I strongly recommend to have a look into Sven's work on the German
mapnik style, which has been trying to address a lot of issues with
localized maps: https://github.com/giggls/mapnik-german-l10n

Sarah

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

Re: [OSM-talk] Abuse of natural=cliff tag

[Sarah Hoffmann]

Hi,

On Fri, Sep 06, 2019 at 02:42:06PM +0200, Vladimir Vyskocil wrote:
> Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>  there is a flagrant 
> misuse and abuse of the usage of the natural=cliff tag. It is used to map the 
> iso altitude lines and not real cliff as stated in the WIKI :
> 
> A cliff  is a vertical or almost 
> vertical natural drop in terrain topography as it occurs for example in form 
> of coastal cliffs or escarpments. The face of the cliff usually consists of 
> bare solid rock but can occasionally also consist of clay, compacted sand, 
> ice or other solid materials.  

I know that area very well and I can assure you, that natural=cliff is no misuse
under this definition. The area is full of rock towers like those:
https://commons.wikimedia.org/wiki/File:20171124195DR_Lohmen_Basteiaussicht_zum_Sieberturm.jpg

That's what you see on the map.

> I already removed the natural=cliff ways mapped by MichaOSM after asking him 
> to fix this but without response the changeset comment was : 
> 
> "Felsen, Riffe, Topografie nach GeoSachsen digitale Geländemodellhoehenlinien 
> 2.5m, digitales Geländereliefmodell, DTK10, topografische Karte”
> 
> For example this changeset : 
> https://www.openstreetmap.org/changeset/66373825#map=15/50.9016/14.3093 
> 
> 
> It say that it used a 2.5m topographic map to map all these false cliffs in 
> this area, he was mapping the topography (MNT) and this is forbidden in OSM.

You missunderstood, he was mapping rock edges. A terrain model is more helpful
for that task than arial imagery. We have permission to use the terrain model
for OSM as far as I know.

I would kindly request that you reinstate deleted natural=cliffs for
the moment. If you are still not convinced from the photo above that the
tagging is correct then we need to have a fundamental discussion first about
how to tag these kind of rock towers. But that would rather be something for
the tagging mailing list (or talk-de if you want to get the locals involved).

Sarah

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

Re: [OSM-talk] osm2pgsql 1.2.0

[Sarah Hoffmann]

Hi,

On Tue, Nov 05, 2019 at 12:16:30AM +0100, wambac...@posteo.de wrote:
> i'm using osm2pgsql-0.96 right now. Is it possible (and meaningful) to
> switch to osm2pgsql-1.2.0?
> 
> Must i change anything in my database? Runing diff updates using a flatfile.

You can switch from 0.96 to 1.2 any time. The database layout
is compatible between the two versions. The only difference is
that 1.x no longer supports old-style multipolygons. That should
not be an issue with the curent planet anyway.

I'd always recommend using the latest release to get the latest fixes.
However, the main performance improvements for 1.2 are noticable during
import. If you prefer a packaged 0.96 over a self-compiled 1.2, then
it's not too much loss to remain with the packages version.

Sarah


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

[OSM-talk] Call for participation SotM 2020 Cape Town ends Sunday, February 23rd

[Sarah Hoffmann]

Hi all,

just a quick remainder that the call for participation for State of the Map 2020
ends this Sunday, February 23rd.

We are looking forward to your proposals for talks, workshops, panels for
a diverse range of topics around OpenStreetMap.

For more information see: https://2020.stateofthemap.org/cfp/

SotM 2020 once more also has an academic track. The call for papers for
this track is open until March 9th.
More inforation at: https://2020.stateofthemap.org/cfp/academic/

We strive to put together a programe that reflects the diversity of our
community. To help with that, please also forward this remainder to your
local OSM groups. And if you know somebody doing exciting work around
OpenStreetMap, don't hesitate to personally encourage them to propose a
talk, especially when they have not held a talk before.

Kind regards

Sarah

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

Re: [OSM-talk] Replication errors

[Sarah Hoffmann]

Hi,

this error has been fixed in the latest release of osmosis.
You need to update your osmosis to a version >= 0.47.2.

Sarah

On Thu, Apr 16, 2020 at 08:10:45AM +0200, Andrzej Kępys wrote:
> Hi All!
> 
> Since few days I have a replication errors using osmosis... Any ideas how to
> fix it? Is there anythink I can do or it's sth about a data?
> 
> ---START
> Thu Apr 16 08:05:01 CEST 2020
> No current.osc file found, downloading new one...
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Osmosis Version 0.46
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Preparing pipeline.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Launching pipeline execution.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Pipeline executing, waiting for completion.
> Apr 16, 2020 8:05:03 AM 
> org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager 
> waitForCompletion
> SEVERE: Thread for task 1-read-replication-interval failed
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to parse xml 
> file /tmp/change8964114732320454958.tmp.  publicId=(null), systemId=(null), 
> lineNumber=1775, columnNumber=22.
>   at 
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:100)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.ReplicationDownloader.processChangeset(ReplicationDownloader.java:107)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.processReplicationFile(BaseReplicationDownloader.java:133)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.download(BaseReplicationDownloader.java:235)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.runImpl(BaseReplicationDownloader.java:271)
>   at 
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.run(BaseReplicationDownloader.java:350)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1775; columnNumber: 22; 
> Invalid byte 2 of 4-byte UTF-8 sequence.
>   at 
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
> Source)
>   at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
>  Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
> Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
>   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
>   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
> Source)
>   at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>   at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
>   at 
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:90)
>   ... 6 more
> Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException: Invalid 
> byte 2 of 4-byte UTF-8 sequence.
>   at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source)
>   at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
>   at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
>   at org.apache.xerces.impl.XMLEntityScanner.scanLiteral(Unknown Source)
>   at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown 
> Source)
>   at 
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
>  Source)
>   ... 16 more
> 
> Apr 16, 2020 8:05:03 AM org.openstreetmap.osmosis.core.Osmosis main
> SEVERE: Execution aborted.
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more tasks 
> failed.
>   at 
> org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
>   at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
>   at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
>   at 
> 

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

Hi,

On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:
> Node 3117603944 was established in 2014 with tags
> addr:city Sørkjosen
> addr:housenumber  45
> addr:postcode 9152
> addr:street   Ringvegen
> 
> Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no results.
> 
> What is going wrong here? Sørkjosen itself is found [2] so the problem does
> not seem to lie in the special character (I wouldn't have thought so). Also
> found is the street which is named Ringveien [3] in OSM. No idea why the
> street is called different than the address node, but does Nominatim not
> index address nodes?

Nominatim only indexes addresses of streets and then searches for
address nodes based on the address of the street they are attached
to.

In that particular example, the housenumber got attached to Hovedvegen
because Nominatim could not find a 'Ringvegen' and used the nearest
street:
https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944

So you get a slightly different address than expected.
Fix the name of the street and everything sorts itself out.

Sarah

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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

On Sun, Aug 23, 2020 at 10:37:48PM +0200, pangoSE wrote:
> Sarah Hoffmann  skrev: (23 augusti 2020 22:20:35 CEST)
> >Nominatim only indexes addresses of streets and then searches for
> >address nodes based on the address of the street they are attached
> >to.
> >
> >In that particular example, the housenumber got attached to Hovedvegen
> >because Nominatim could not find a 'Ringvegen' and used the nearest
> >street:
> >https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944
> >
> >So you get a slightly different address than expected.
> >Fix the name of the street and everything sorts itself out.
> 
>  thanks for the explanation and link. Are these very useful get parameters 
> documented somewhere? 

https://nominatim.org/release-docs/develop/api/Details/

Use the details page without any paramaters to get a form where
you can select which OSM object to show information about:
https://nominatim.openstreetmap.org/ui/details.html

Sarah

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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Sarah Hoffmann]

On Mon, Aug 24, 2020 at 07:28:42AM +0200, Maarten Deen wrote:
> On 2020-08-23 22:20, Sarah Hoffmann wrote:
> > Hi,
> > 
> > On Sun, Aug 23, 2020 at 09:41:10PM +0200, Maarten Deen wrote:
> > > Node 3117603944 was established in 2014 with tags
> > > addr:city Sørkjosen
> > > addr:housenumber  45
> > > addr:postcode 9152
> > > addr:street   Ringvegen
> > > 
> > > Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no
> > > results.
> > > 
> > > What is going wrong here? Sørkjosen itself is found [2] so the
> > > problem does
> > > not seem to lie in the special character (I wouldn't have thought
> > > so). Also
> > > found is the street which is named Ringveien [3] in OSM. No idea why
> > > the
> > > street is called different than the address node, but does Nominatim
> > > not
> > > index address nodes?
> > 
> > Nominatim only indexes addresses of streets and then searches for
> > address nodes based on the address of the street they are attached
> > to.
> > 
> > In that particular example, the housenumber got attached to Hovedvegen
> > because Nominatim could not find a 'Ringvegen' and used the nearest
> > street:
> > https://nominatim.openstreetmap.org/ui/details.html?osmtype=N=3117603944
> 
> Just one question though (well two acutally): why does it find Hovedvegen as
> nearest street and not Reingveien
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=W=282670088
> ?

Hovedvegen is closer. Nominatim computes distance in WSG84 while you look at a
Mercator map. That far north there is a significant distortion between the two.

> And would it be an idea to make some kind of fuzzy matching when searching
> for names? Like "it is better to take a street which has just one different
> letter then one where all differ"?

This is about consistency between addr:street and names on highways. I think
it is much better to fix the OSM data in this case. Nominatim has always taken
a stance to rather expose mapping issues than trying to work around them.

Sarah

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

Re: [OSM-talk] Building a tile-server

[Sarah Hoffmann]

On Wed, Jul 01, 2020 at 03:18:30PM -0500, Tom Browder wrote:
> I am running Debian Buster on a bare-iron dedicated server with 32 Gb
> RAM, 32 cores, and a single 4 TB spinning disk. I am running Pg 12
> (the version maintained by the Pg developers) with its default
> configuration.
> 
> My PostGIS is the latest Debian package version (version ?). osm2pgsql
> is also a package (version ?).
> 
> Should I compile those from source?

Make sure to use osm2pgsql from backports. This always has
the newest released version.

Be aware that you'll likely need osm2pgsql 1.2.2 at the moment
to import a planet. If your import gets stuck when reading
relations then your osm2pgsql is too old.

osm2pgsql 1.2.2 should be available in backports in a couple of
days.

Sarah

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

Re: [OSM-talk] OSM Carto not updating

[Sarah Hoffmann]

Hi,

short update on the issue: libosmium has just made a new release
that fixes the issue: https://github.com/osmcode/libosmium/releases/tag/v2.15.6

osm2pgsql and Nominatim will get new bug-fix releases with the
new libosmium version by today or tomorrow.

You can already download the new libosmium and build osm2pgsql
against that to get a fixed version.

If that is not an option, you can get your installation unstuck for now
by patching the configuration to ignore the offending Klamath forst.

For openstreetmap-carto, add the following patch to your
openstreetmap-carto.lua file:
https://gist.github.com/lonvia/ab7db4156bbfbcf8ebe1ba8185c2e66c

For Nominatim, you need to skip the relation in the import style
file configured through the CONST_Import_Style variable. This
would be settings/import-full.style per default. You need to add
the lines as in this patch:
https://git.openstreetmap.org/nominatim.git/commitdiff/f9ba2af
(careful, the osm.org installation uses import-extratags.style.
 You must apply the patch to the style file you use. Just make
 sure the lines are added at the top of the file.)

In both cases: after you have applied the patch, kill osm2pgsql
and then restart your update process as usual.

Kind regards

Sarah


On Sat, Jun 27, 2020 at 06:25:11PM -0400, Lynn W. Deffenbaugh (Mr) wrote:
> Where is #osm-dev?  I'd like to listen in as my updates are also stalling
> with osm2pgsql ramping up to 100% while processing relations.
> 
> Lynn (D) - Running a planet-wide tile server with updates...  (or trying
> to!)
> 
> On 6/27/2020 11:20 AM, Marc M. wrote:
> > Hello,
> > 
> > Le 27.06.20 à 17:04, ET Commands a écrit :
> > > Is something wrong with the OSM Carto servers?
> > one diff freeze the update
> > sequenceNumber=4082799
> > timestamp=2020-06-26T19:17:02Z
> > ppl on #osm-dev are working on this.
> > 
> > Regards,
> > Marc
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-de] Eigener Overlay: FOSSGIS-Server oder toolserver.org?

[Sarah Hoffmann]

Hoi,

On Tue, Jun 01, 2010 at 08:52:32AM +0200, Florian Lohoff wrote:
 Ich benutze einen OpenLayers Vector Layer:
 
 http://dev.openlayers.org/releases/OpenLayers-2.9.1/doc/apidocs/files/OpenLayers/Layer/Vector-js.html
 
 und lade die Daten via GeoJSON nach:
 
 http://dev.openlayers.org/releases/OpenLayers-2.9.1/doc/apidocs/files/OpenLayers/Format/GeoJSON-js.html
 
 Der code sieht dann vereinfacht so aus:
 
   geojsonparser = new OpenLayers.Format.GeoJSON();
   vector = new OpenLayers.Layer.Vector(data);
   map.addLayer(this.vector);
 
 Beim pan'nen oder zoomen gibts dann nen callback in dem ich via ajax daten 
 nachlade die
 das CGI Script (perl) mit JSON.pm rausnudelt. Die parse ich dann mit dem 
 parser uns schiebe
 die in den vector layer:
 
   var features = geojsonparser.read(result.responseText);
   vector.destroyFeatures();
   vector.addFeatures(features);

Das geht noch einfacher mit den Strategies die OpenLayers mitliefert.
Etwa so:

vector = new OpenLayers.Layer.Vector(data, {
strategies: [new 
OpenLayers.Strategy.BBOX({ratio : 1})],

protocol: new OpenLayers.Protocol.HTTP({

  url: http://www.foo.com/bar;,

format: new 
OpenLayers.Format.GeoJSON()

})

});

Das macht dann das Nachladen automatisch, wenn die Karte bewegt oder
gezoomt wird.

Gruss

Sarah

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

Re: [Talk-de] Eigener Overlay: FOSSGIS-Server oder toolserver.org?

[Sarah Hoffmann]

On Tue, Jun 01, 2010 at 03:04:25PM +0200, Florian Lohoff wrote:
 On Tue, Jun 01, 2010 at 02:15:20PM +0200, Sarah Hoffmann wrote:
  Das geht noch einfacher mit den Strategies die OpenLayers mitliefert.
  Etwa so:
  
  vector = new OpenLayers.Layer.Vector(data, {
  strategies: [new 
  OpenLayers.Strategy.BBOX({ratio : 1})],
  
  protocol: new OpenLayers.Protocol.HTTP({
  
url: http://www.foo.com/bar;,
  
  format: new 
  OpenLayers.Format.GeoJSON()
  
  })
  
  });
  
  Das macht dann das Nachladen automatisch, wenn die Karte bewegt oder
  gezoomt wird.
 
 Wie machst du das dann an die features noch styles zu haengen? So wuerden
 ja die rohen features in die vector layer genagelt 

Die Styles werden im GeoJOSN mitgeliefert und dann per StyleMap zugewiesen.
Sprich, ein Eintrag in der GeoJOSN-Datei sieht etwa so aus:

{ type: Feature,   geometry: {type: Point, coordinates: [8.545645, 
47.4117363]}
,properties: {
graphic: circle,
name: Bahnhof Oerlikon 781,
color: #0ff,
bgcolor: #000}}

Die Style-Map etwa so:

  var stylemap = new OpenLayers.StyleMap(
 {default :   { pointRadius : 3,
  fillColor: ${color},
  strokeColor: ${bgcolor},
  graphicName: ${graphic},
  label: ${name},
  strokeWidth: 1
  });

Mit $ markierte Variablen werden durch die 'properties' aus dem GeoJOSN
ersetzt.

Dann die Style-Map beim Initialisieren des Vektor-Layers übergeben:

vector = new OpenLayers.Layer.Vector(data, {
strategies: [new OpenLayers.Strategy.BBOX({ratio : 1})],
protocol: new OpenLayers.Protocol.HTTP({
url: http://www.foo.com/bar;,
format: new OpenLayers.Format.GeoJSON()
}),
 styleMap: stylemap
});

Gruss

Sarah

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

Re: [Talk-de] Vector layer mit strategie/protocol.HTTP Was: Eigener Overlay: FOSSGIS-Server oder toolserver.org?

[Sarah Hoffmann]

On Tue, Jun 01, 2010 at 04:09:37PM +0200, Florian Lohoff wrote:
 On Tue, Jun 01, 2010 at 03:36:24PM +0200, Sarah Hoffmann wrote:
 Jetzt muss ich das SRS900913 vs WGS84 nochmal klaeren - Die URL wirft bei
 strategie/protocol.http natuerlich die default projection des layers mit
 raus und keinen zoom level. D.h. anstatt
 
 /cgi-bin/getdata2?b=51.82844228767418t=51.84265608515574l=8.314342412719814r=8.363180074460946zoom=15data=maxspeed
 
 kriege ich ein:
 
 /cgi-bin/getdata2?bbox=923809.42114287,6769035.8748913,929246.00477867,6771596.5153383

Die Projektion sollte eigentlich die des Layers sein. Sprich, einfach 
noch die Option 
  projection : new OpenLayers.Projection(EPSG:4326)
beim erstellen des Vector-Layers hinzufügen. Dann sollte es gehen. Allerdings
ist es am klügsten, wenn du den Vektor-Layer in der gleichen Projektion hast,
wie die Daten im GeoJOSN, sonst wird beim Laden jedes Feature einzeln
umprojeziert.

'data=maxspeed' kannst du wohl einfach an die URL anhängen. 

Für das Problem mit dem Zoom habe ich allerdings auch keine befriedigende
Lösung gefunden, sondern die moveEnd()-Funktion gehackt:

moveEnd: function(obj) {
  if (this.curzoom  this.map.zoom) {
this.refresh({force : true});
  }
  this.curzoom = this.map.zoom;
}

Damit wird das Neuladen erzwungen, wenn hereingezoomt wird. (Welche Features
geladen werden, wird durch die Grösse des Gebiets bestimmt, i.e. bei der
Datenbankabfrage gibt es ein 'limit 200'. Daher brauche ich das nicht in
der URL.) Wenn du da eine bessere Lösung findest, bin ich ganz Ohr.

Gruss

Sarah

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

Re: [Talk-de] Vector layer mit strategie/protocol.HTTP Was: Eigener Overlay: FOSSGIS-Server oder toolserver.org?

[Sarah Hoffmann]

On Tue, Jun 01, 2010 at 07:21:49PM +0200, Florian Lohoff wrote:
 On Tue, Jun 01, 2010 at 04:37:25PM +0200, Sarah Hoffmann wrote:
  Die Projektion sollte eigentlich die des Layers sein. Sprich, einfach 
  noch die Option 
projection : new OpenLayers.Projection(EPSG:4326)
  beim erstellen des Vector-Layers hinzufügen. Dann sollte es gehen. 
  Allerdings
  ist es am klügsten, wenn du den Vektor-Layer in der gleichen Projektion 
  hast,
  wie die Daten im GeoJOSN, sonst wird beim Laden jedes Feature einzeln
  umprojeziert.
 
 Eben - d.h. entweder ich nutze die BBOX in 900913 und lasse PostGIS die bbox 
 erst
 in EPSG:4326 umprojezieren und das ergebniss des statements wieder
 zu EPGS:900913. Oder ich mache den vector layer komplett in 4326 und lasse
 das Javascript umprojezieren - Viel CPU auf dem Client.

Ich bin verwirrt. Warum überhaupt 900913 verwenden, wenn deine Datenbank
im 4326 ist? Display-Projection deiner Karte ist auch 4326. Wenn also deine
Datenbank in 4326 ist, die BBOX-Anfrage in 4326 ankommt, du die Daten im
GeoJOSN in 4326 auslieferst und dein Vektor-Layer in 4326 ist, dann 
ist keine Umrechnung nötig, weder im Server noch im Client.

  Für das Problem mit dem Zoom habe ich allerdings auch keine befriedigende
  Lösung gefunden, sondern die moveEnd()-Funktion gehackt:
  
  moveEnd: function(obj) {
if (this.curzoom  this.map.zoom) {
  this.refresh({force : true});
}
this.curzoom = this.map.zoom;
  }
  
  Damit wird das Neuladen erzwungen, wenn hereingezoomt wird. (Welche Features
  geladen werden, wird durch die Grösse des Gebiets bestimmt, i.e. bei der
 
 Ich habe ja nicht das problem das ich neu laden muss sondern das ich den zoom
 level an das cgi mitliefern will. Ich mache z.b. auch teilweise vom zoomlevel
 abhaengig was ich darstelle. In der maxspeed map sieht man ab zoom 16 oder 17
 dann kleine Schilder auf den Straßen.

Das sollte funktionieren, wenn du zusätzlich den entsprechenden
Parameter im Protocol-Objekt änderst.

  Datenbankabfrage gibt es ein 'limit 200'. Daher brauche ich das nicht in
  der URL.) Wenn du da eine bessere Lösung findest, bin ich ganz Ohr.
 
 Aeh - das finde ich doof - Weil dann wie bei keepright oder openstreetbugs 
 einfach nur mal 200 elemente an einer random position im sichtbereich 
 auftauchen. 
 Koennte den betrachter dazu verleiten zu glauben das das alles ist.
 
 Deshalb werfe ich den zoom mit in das CGI script im Ajax request und im CGI 
 script sage ich dann 
 
   if ($zoom  14) {
   return {}
   }
 
 Dann ist nichts sichtbar ... Schoen waere noch einen status mitzuliefern der
 dargestellt wird, nach dem motto Please zoom to show elements - Aber das ist
 wieder nicht so schoen mit GeoJSON zu machen ...
 
 Ich hatte mal ueberlegt eben den response string zu zerlegen. D.h. erste
 zeile ist status und dann folgt das GeoJSON so in der art.

Der GeoJOSN-Standard definiert, dass man der Datei beliebige Attribute
mitgeben kann. Leider wirft OpenLayers diese weg. Da muss man wohl mal
eine Erweiterung bauen.

Ich dachte eher daran, Server-seitig eine Gruppierungsfunktion zu bauen.
OpenLayers hat soetwas ja mit der Paging-Strategy, aber leider gruppiert
die nur fertige Features, was bedeutet, dass sie immernoch unter dem
200-Feature-Maximum von OpenLayers leidet. 

Gruss

Sarah

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

Re: [Talk-de] Vector layer mit strategie/protocol.HTTP Was: Eigener Overlay: FOSSGIS-Server oder toolserver.org?

[Sarah Hoffmann]

On Tue, Jun 01, 2010 at 10:07:02PM +0200, Lars Lingner wrote:
 On 01.06.2010 19:21, Florian Lohoff wrote:
 [...]
  
  Datenbankabfrage gibt es ein 'limit 200'. Daher brauche ich das nicht in
  der URL.) Wenn du da eine bessere Lösung findest, bin ich ganz Ohr.
  
  Aeh - das finde ich doof - Weil dann wie bei keepright oder openstreetbugs 
  einfach nur mal 200 elemente an einer random position im sichtbereich 
  auftauchen. 
  Koennte den betrachter dazu verleiten zu glauben das das alles ist.
  
 
 Erstmal sorry das ich hier in den Thread so reinplatze. Kennt Ihr die
 cluster strategy von OpenLayers [1] ?
 
 Damit lassen sich nahe beieinander liegende Elemente gruppieren. Beim
 hineinzoomen teilen sie sich immer weiter auf, je nachdem wieviel Platz ist.
 
 Könntet Ihr damit was anfangen? Es wäre schön eine sinnvolle Nutzung mal
 zu sehen.

Die Strategie meinte ich. Leider ist sie für diesen Fall nur begrenzt
anwendbar. Meine Datenbank hat 25.000 Einträge, die kann ich unter keinen
Umständen mit einmal laden ohne den Browser zu überlasten. Deswegen muss
das Clustering bereits server-seitig geschehen.

Gruss

Sarah

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

Re: [Talk-de] incremental update einer osm sql-database - geht das?

[Sarah Hoffmann]

On Tue, Jun 08, 2010 at 08:23:08AM -0700, Walter Nordmann wrote:
 
 hi,
 
 derzeit hole ich mir für bestimmte auswertungen (z.b. dortmund) die dayly
 oder hourly change-files von planet.openstreetmap.org, merge die mit osmosis
 in das aktuelle osm-file und werte dann in perl das neue aktualisierte
 osm-file aus.
 
 funktioniert eigentlich prima aber es dauert halt verdammt lange. und ist
 doch sehr unflexibel.
 
 macht es sinn, das ganze auf sql (postgresql oder lieber noch mysql)
 umzustellen?
 
 konkreter: kann man mit einen planet change-file eine sql-datenbank auf dem
 aktuellen stand halten?

Es ist kein Problem, wenn dir das simple-Schema von Osmosis ausreicht.
Datenbank mit dem Skript script/pgsql_simple_schema_0.6.sql anlegen,
dein osm-File mit --write-pgsql-Task importieren und dann beim Updated
einfach den --write-xml-change-Task durch den --write-pgsql-change-Task
ersetzen.

Auf meiner Maschine (DualCore mit 2GB RAM) dauert das Update für 24 Stunden
(also 24 hourly change-files oder 1 daily change-file)  etwa 1.5h, wenn 
keine Geometrien für die Objekte erstellt werden. Wie lange im Vergleich 
dazu das Update einer osm-Datei braucht, habe ich nicht probiert.

Noch ein kleiner Hinweis: achte darauf, dass beim Anlegen der Datenbank
ein Index über das Feld relation_id in der Tabelle relation_members
erstellt wird. Bis vor zwei Wochen fehlte das im Skript.  Ohne diesen 
Index kann das Update mal schnell 8 Stunden brauchen.

Gruss

Sarah

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

Re: [Talk-de] Zwei Fragen zu Wanderwegen

[Sarah Hoffmann]

On Mon, Jun 28, 2010 at 07:41:49AM +0200, André Joost wrote:
 Am 27.06.10 17:43, schrieb Manuel Reimer:
 Hallo,

 ich hätte mal zwei Fragen zu Wanderwegs-Relationen:

 - Ist es möglich die Laufrichtung anzugeben? Bei einigen Wegen ist die
 Beschilderung nur aus einer Richtung eindeutig. Ein Laufen in der
 falschen Richtung ist mit einer Karte zwar auch möglich, aber nach den
 Wanderzeichen ist dann intensiver zu suchen.

 Ich hab da in der relation
 oneway=yes in Verbindung mit role=forward/backward in Gebrauch. Bei  
 Rundwanderwegen könnte man auch clockwise/anti_clockwise nehmen.

Wobei mir nicht ganz klar ist, worauf sich forward/backward bezieht,
auf die Ordnung der Wege innerhalb der Relation oder auf die Richtung
des Weges selbst?

Gruss

Sarah

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

Re: [Talk-de] Ein Icon pro Relation

[Sarah Hoffmann]

On Wed, Jul 21, 2010 at 10:50:50PM +0200, Thomas Ineichen wrote:
 Hallo zusammen,
 
 Auf  meiner  Jogging-Karte  möchte  ich  gerne  für  tiefere Zooms pro
 Strecke/Relation  ein  Jogging-Icon  anzeigen. Da die route-Relationen
 aber  nur  indirekt  in der PostGIS-Datenbank gespeichert sind, ergibt
 dies auf der Karte eine zufällige Anzahl von Icons:
 http://toolserver.org/~ti/ftm/test.html?zoom=15lat=47.34045lon=8.64565layers=BFTTF
 
 Gibt  es  eine einfache Möglichkeit, pro Relation nur *ein* Icon anzu-
 zeigen?

Ich würde das schon bei der Datenbankabfrage clustern. Ich kenne den
genauen Aufbau der DB auf dem Toolserver nicht, aber ganz grob könnte
das in SQL so aussehen:

SELECT ST_Centroid(ST_Collect(geom)) FROM relations_tabelle
WHERE ... GROUP BY relation_id;

Gruss

Sarah

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

Re: [Talk-de] Realtion Analyzer, Wanderweg

[Sarah Hoffmann]

Hoi Markus,

On Mon, Jun 01, 2009 at 11:25:45AM +0200, Markus wrote:
 Habe gestern eine Relation (Wanderweg) eingegeben,
 aber der Relation Analyzer findet sie nicht.
 
 Im JOSM wird sie angezeigt (Jura-Höhenweg, Nr. 150262)
 
 Woran könnte das liegen?

Der Jura-Höhenweg sollte als network=nwn, ref=5 getaggt werden.

Es gibt eine Seite für das Schweizer Wanderwegenetz:

http://wiki.openstreetmap.org/wiki/DE:Switzerland/HikingNetwork

Wenn du dich daran hälst, kannst du das Ergebnis mit einem
Tag Verzögerung auch hier begutachten:

http://osm.lonvia.de/hiking.html

Den E4 würde ich dann in eine eigene Relation mit network=iwn packen, 
nicht als Superrelation, sondern alle Elemente einzeln.

Gruss

Sarah

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

Re: [Talk-de] Strassen in der Schweiz, Solothurn

[Sarah Hoffmann]

On Sun, May 31, 2009 at 10:29:20PM +0200, Markus wrote:
 Verwenden die Schweizer andere Attribute für Strassen?
 Im Zusammenhang mit dem Import in Solothurn erscheinen mitten im Wald 
 lange highway=service, Forstwege haben keinen Trackgrade, 
 highway=unclassified scheint es keine zu geben.
 
 Fehler oder Absicht?

Das kam so vom Import der offiziellen Daten. Die Attribute für
Strassen sind in der Schweiz ähnlich der deutschen, siehe:

http://wiki.openstreetmap.org/wiki/EN:CH:Map_Features#Highway

Für highway=service und tracks gelten genau die gleichen Regeln,
also trackgrade ruhig anfügen und highway=service ändern, wenn
es nicht passt.

Gruss

Sarah

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

Re: [Talk-de] Wanderkarte für Schweiz und Südtirol

[Sarah Hoffmann]

Hoi Nop,

On Thu, Jul 16, 2009 at 09:26:58AM +0200, Nop wrote:
 Die Wanderkarte wurde jetzt (rechtzeitig zur Mapping Party :-) um 
 Südtirol und die östliche Schweiz erweitert. Die westliche Schweiz folgt 
 in ein paar Tagen.

Wir haben hier in der Schweiz ein bisschen ein anderes Wanderrouten-
System. Neben den benannten Routen gibt es ein ausgedehntes Netz
markierter Wege mit überall einheitlicher Markierung. Das dazu-
gehörige Taggingschema ist auch im Wiki zu finden:

http://wiki.openstreetmap.org/wiki/DE:Switzerland/HikingNetwork
(Teil Wanderwegenetz)

Beispiel-Relation: 
http://www.openstreetmap.org/browse/relation/151141

Leider werden diese lokalen Routen in deiner Karte nicht gerendert,
weil diese Routen keine Namen haben. Da es Tagging für den Renderer 
wäre, jetzt irgendwelche Namen zu erfinden, wäre es schön, wenn du
diese Routen auch ohne Namen rendern könntest. Korrekte 
osmc:symbol-Tags sind ja vorhanden.

Wenn sie nicht im Routenverzeichnis auftauchen, ist das okay.

Gruss

Sarah

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

Re: [Talk-de] Wanderkarte für Schweiz und Südtirol

[Sarah Hoffmann]

On Thu, Jul 16, 2009 at 03:02:14PM +0200, ekkeh...@gmx.de wrote:
 
 Hallo!
 
  On Thu, Jul 16, 2009 at 09:26:58AM +0200, Nop wrote:
  
  Wir haben hier in der Schweiz ein bisschen ein anderes Wanderrouten-
  System. Neben den benannten Routen gibt es ein ausgedehntes Netz
  markierter Wege mit überall einheitlicher Markierung. Das dazu-
  gehörige Taggingschema ist auch im Wiki zu finden:
  
  http://wiki.openstreetmap.org/wiki/DE:Switzerland/HikingNetwork
  (Teil Wanderwegenetz)
 
 Die Eigenarten der Schweizer Wanderwege haben wir abseits der Mailingliste 
 schon mal diskutiert. Es ist eigentlich kein Problem, den Relationen des 
 Wegenetzes einen beschreibenden Namen mit örtlichem Bezug zu geben. 
 
 Musterbeispiel ist die Relation 103607 Wanderwege St. Gallen.

Dann hast du aber plötzlich hunderte Relationen mit dem gleichen Namen,
denn nicht das gesamte Netz des Kantons St. Gallen ist in der
gleichen Relation. Das ist von der Grösse her schon nicht machbar.

Der beschreibende Name, der auch für die Editoren benutzt wird, findet
sich im note-Tag, wo er IMHO eher hingehört. Der Operator gehört
ins operator-Tag. Dass der Wanderwerg im Kanton St. Gallen liegt,
kann man aus den Koordinaten ableiten.

 
  Leider werden diese lokalen Routen in deiner Karte nicht gerendert,
  weil diese Routen keine Namen haben. Da es Tagging für den Renderer 
  wäre, jetzt irgendwelche Namen zu erfinden, wäre es schön, wenn du
  diese Routen auch ohne Namen rendern könntest.
 
 Die Routen sind nicht in die Karte aufgenommen, weil ich sie ohne weitere 
 Kenntnisse nicht als sinnvolle Wanderrouten erkennen bzw nicht von 
 unvollständigen Relationen und fehlerhaften Einträgen unterscheiden kann. 

Dann kommen wir an diesem Punkt leider nicht weiter. Ich verstehe nicht,
wie eine Route ohne Name (aber sonst vollständigem Tags) korrekter sein 
soll als eine, die mit einem frei erfunden Namen daherkommt.

Gruss

Sarah

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

Re: [Talk-de] Wanderkarte für Schweiz und Südtirol

[Sarah Hoffmann]

On Thu, Jul 16, 2009 at 07:16:03PM +0200, Nop wrote:
  Musterbeispiel ist die Relation 103607 Wanderwege St. Gallen.
  
  Dann hast du aber plötzlich hunderte Relationen mit dem gleichen
  Namen, denn nicht das gesamte Netz des Kantons St. Gallen ist in der 
  gleichen Relation. Das ist von der Grösse her schon nicht machbar.
 
 Das wäre dann schon mal ein Name, der zusammengehörende Elemente 
 gruppiert - und damit deutlich besser, als hunderte 
 durcheinandergewürfelte Relationen ohne Namen. 

Falsch, das ergibt eine Gruppierung nach Kanton und da greift die Regel

http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Es mag durchaus Gründe geben, ganze Wandernetze in eine Relation zu packen,
aber die scheinen alle unter die Kategorie 'Handhabbarkeit' zu fallen.
Und dann ist es besser die Tools zu verbessern, als an die Daten
anzupassen.

 Offensichtlich läßt sich 
 das Benennungsschema aber noch verbessern. Nach welchen Kriterien wählst 
 Du denn beim Mappen die richtige Relation aus? Oder packst Du den Weg 
 einfach wahllos irgendwo rein?

[ ] Du hast die Wiki-Seite gelesen, auf die ich verwiesen habe.

Eine Route ist die Verbindung zwischen zwei Wegweisern. Wegweiser haben
hier (meistens) einen Namen und referenzieren sich somit gegenseitig.
Das ergibt zusammen mit den Markierungen eine ausgeschilderte,
objektiv verfolgbare Route.

 Mit der Wanderkarte gebe ich mir sehr viel Mühe, daß die dargestellten 
 Routen von hoher Qualität sind und das Wegeverzeichnis auch brauchbar. 
 Pro Update bearbeite ich die Symbole von 50-100 Routen - und ja, das ist 
 notwendig, die Fehlerrate ist auch bei den osmc:symbol Tags noch hoch.

Es ist schön, dass du soviel Arbeit in die Karte steckst. Es wäre noch
schöner, wenn du mehr Vertrauen in deine Mitmapper hättest. Die sind
nicht perfekt, aber im Durchschnitt ganz brauchbar. ;)

 Ich verstehe nicht warum Du Dich dem so verwehrst daß eine Relation 
 nicht einen hilfreichen Namen haben _darf_.

Siehe Antwort von Frederik.

Gruss

Sarah

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

Re: [Talk-de] Wanderkarte für Schweiz und Südtirol

[Sarah Hoffmann]

On Fri, Jul 17, 2009 at 12:11:39AM +0200, Nop wrote:
 Dann reduziert sich das Problem schlichtweg darauf: Eigentlich wollen 
 wir das Gleiche. Nur mit unterschiedlichen Tags.
 
 Für Dich heißt es in Deiner Beispielrelation:
 
 note = Staubern-Kastensattel
 name = fehlt
 
 Für mich ist das ein Mißbrauch von note [1], da es keine ergänzende 
 Mitteilung für Mapper/Bearbeiter ist sondern eine handfeste 
 Kennzeichnung der Relation.

Als ich das note-Tag in das Proposal eingefügt habe, war sein einziger
Zweck, eine Hilfe für die Mapper/Bearbeiter zu sein, damit sie die
Relation in ihrem Lieblingseditor wiederfinden. Passt also ausgezeichnet.

Aber gut, einen entsprechenden Hinweis im Wiki gibt es bereits und ich habe
das ganze auch nach talk-ch kommuniziert. Möge jeder Mapper selber
entscheiden, ob er ein name-Tag hinzufügt oder nicht.

Für nicht ganz perfekte Schweizer Wanderrouten habe ich
http://osm.lonvia.de/hiking.html aufgesetzt.

Und damit wende ich mich wieder der praktischen Arbeit zu. Nur noch
etwas mehr als 59.000km Wanderwege, die zu erfassen sind. ;)

Gruss

Sarah
 

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

Re: [Talk-de] Wanderkarte für Schweiz und Südtirol

[Sarah Hoffmann]

Hoi,

On Tue, Jul 21, 2009 at 08:00:05PM +0200, Nop wrote:
 Sarah Hoffmann schrieb:
  Als ich das note-Tag in das Proposal eingefügt habe, war sein einziger
  Zweck, eine Hilfe für die Mapper/Bearbeiter zu sein, damit sie die
  Relation in ihrem Lieblingseditor wiederfinden. Passt also ausgezeichnet.
  
  Aber gut, einen entsprechenden Hinweis im Wiki gibt es bereits und ich habe
  das ganze auch nach talk-ch kommuniziert. Möge jeder Mapper selber
  entscheiden, ob er ein name-Tag hinzufügt oder nicht.
 
 Es gibt jetzt Kompromißlösung.
 
 Nachdem Einige das name-Tag und ich das note-Tag für den falschen Ort 
 für eine angenäherte Bezeichnung halten, wertet der Renderer jetzt 
 zusätzlich das Spezialtag osmc:name aus. Damit kann alternativ eine 
 Route für das Wegeverzeichnis sinnvoll benannt und auf die Karte 
 gebracht werden.

Ok, das ist ein guter Kompromiss. Ich habe das jetzt im Wiki nachgetragen.

Aggregierst du eigentlich über die Namen? Ist es also möglich (oder
vielleicht sogar gewünscht?) mehreren lokal naheliegenden den gleichen
Namen zu geben, damit sich das Wegeverzeichnis nicht plötzlich mit
hunderten kleiner 1km langer Routen füllt?

Gruss

Sarah

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

Re: [Talk-de] Permalink bei Lonvia's World Hiking Map

[Sarah Hoffmann]

On Thu, Mar 18, 2010 at 12:14:43PM +0100, Christian Knorr wrote:
 Hallo zusammen,
 der Permalink in http://osm.lonvia.de/world_hiking.html verlinkt auf
 http://osm.lonvia.de/world_hiking.html?http%3A%2F%2Fosm.lonvia.de%2Fworld_hiking.html=zoom=5lat=51.5lon=-0.1layers=FFBT
 
 Wenn man das auf
 http://osm.lonvia.de/world_hiking.html?zoom=5lat=51.5lon=-0.1layers=FFBT
 kürzt, nimmt der Permalink dieses Muster dauerhaft und die zweite URL 
 erscheint nicht mehr.
 
 Ist das so beabsichtigt?

Ist es nicht. Da hat es einen Bug in OpenLayers. Mit Hilfe deiner Beschreibung
war die Ursache leicht zu finden. Ich habe es gefixt. 

Gruss

Sarah

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

Re: [Talk-de] Wanderwege

[Sarah Hoffmann]

On Wed, Mar 31, 2010 at 10:38:40PM +0200, Gerd v. Egidy wrote:
 Da denkt sich dann halt jeder Mapper vor Ort was aus. Das macht es aber nicht 
 ganz so einfach bereits erfasste Teilstrecken zu finden und in einer Relation 
 zusammenzuführen.
 
 Für mich wäre es daher eine große Hilfe, von diesen ganzen kleineren, 
 regionalen Wanderwegen eine Liste zusammenzubekommen. Wenn man das z.B. als 
 Wiki pflegt, könnte man auch gleich die Relationsnummern dazupacken sobald 
 man 
 sie angelegt hat.

Meine Wanderkarte[1] hat seit einigen Tagen ein kleines Feature namens
Routes in der unteren linken Ecke. Damit kann man sich die Wanderrouten
im aktuellen Bildausschnitt anzeigen lassen. Das ganze ist noch etwas im
Beta-Stadium (unter anderem zur Zeit nur unter Firefox getestet), aber 
zum Finden bereits vorhandener Relationen sollte es sich bereits ganz gut
eignen.

Gruss

Sarah

[1] http://osm.lonvia.de/world_hiking.html


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

Re: [Talk-de] Wanderwege

[Sarah Hoffmann]

On Thu, Apr 01, 2010 at 08:58:56AM +0200, Stephan Olbrich wrote:
  Meine Wanderkarte[1] hat seit einigen Tagen ein kleines Feature namens
  Routes in der unteren linken Ecke. Damit kann man sich die Wanderrouten
  im aktuellen Bildausschnitt anzeigen lassen. Das ganze ist noch etwas im
  Beta-Stadium (unter anderem zur Zeit nur unter Firefox getestet), aber
  zum Finden bereits vorhandener Relationen sollte es sich bereits ganz gut
  eignen.
 
 Tolles Feature! Ich hätte da gleich noch ein paar Vorschläge/Wünsche:
 Wäre es möglich, den Wanderweg hervorzuheben, der gerade ausgewählt ist?
 Kannst Du in der Liste und in der Detailansicht auch das Symbol anzeigen?

Beides ist bereits in der Planung, genauso wie eine deutsche Übersetzung
des Interfaces. Ich hoffe, dass ich in den nächsten Wochen etwas Zeit
finde.

Gruss

Sarah

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

Re: [Talk-de] Wanderwege

[Sarah Hoffmann]

On Thu, Apr 01, 2010 at 09:07:07AM +0200, Stephan Olbrich wrote:
   Meine Wanderkarte[1] hat seit einigen Tagen ein kleines Feature namens
   Routes in der unteren linken Ecke. Damit kann man sich die Wanderrouten
   im aktuellen Bildausschnitt anzeigen lassen. Das ganze ist noch etwas im
   Beta-Stadium (unter anderem zur Zeit nur unter Firefox getestet), aber
   zum Finden bereits vorhandener Relationen sollte es sich bereits ganz gut
   eignen.
  
  Tolles Feature! Ich hätte da gleich noch ein paar Vorschläge/Wünsche:
  Wäre es möglich, den Wanderweg hervorzuheben, der gerade ausgewählt ist?
  Kannst Du in der Liste und in der Detailansicht auch das Symbol anzeigen?
 
 und noch eine Kleinigkeit: Momentan wird beim Klicken auf Routes die Karte 
 nach rechts geschoben um Platz für die Box zu machen. Wäre es möglich die Box 
 einfach drüber zu legen? Dann muss man nicht erst wieder suchen wo man auf 
 der 
 Karte ist.

Darüberlegen geht nicht, weil dann die Zoom-Leiste verschwindet. Da müsste
man schon die Karte anpassen, was nicht ganz trivial ist. Ich schau mir
das mal an.

Gruss

Sarah

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

Re: [Talk-de] Wanderwege

[Sarah Hoffmann]

Hallo Markus,

On Fri, Apr 02, 2010 at 12:43:58PM +0200, Markus wrote:
 Weisst Du warum in meiner Gegend auf Deiner Karte Routen nicht angezeigt 
 werden, aber auf der Karte von Klaus schon?
 Beispiesweise roter Ring auf weissem Grund:
 http://osm.lonvia.de/world_hiking.html?zoom=14lat=49.60923lon=11.35325layers=FFBT
 http://topo.geofabrik.de/?lon=11.3374lat=49.6113zoom=14
 http://www.lau-net.de/baerlocher/osm/Simmelsdorf.php?zoom=14lat=49.61222lon=11.34505layers=B00FTTFFFTT

Du meinst hier den Hüttenbacher Rundweg? Der ist auf der Karte schon
drauf, allerdings gekennzeichnet als 'HR' auf violettem Grund. Das liegt
daran, dass der Relation ein maschinenlesbares osmc:symbol-Tag[1] fehlt.
Im Gegensatz zu Nop mache ich keine manuelle Nachbearbeitung der Daten, 
um eine tagesaktuelle Karte bieten zu können. Die Information im symbol-Tag
kann der Renderer nicht ohne menschliche Hilfe verstehen.

Seit neustem versucht der Renderer ein bisschen cleverer zu sein und
generiert aus dem Relations-Namen ein Symbol, wenn er gar keine verwert-
baren Informationen finden kann (also kein verständliches osmc:symbol-
oder ref-Tag). Deswegen das Symbol 'HR' für den Weg.

Gruss

Sarah

[1] http://wiki.openstreetmap.org/wiki/DE:Key:osmc:symbol

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

Re: [Talk-de] Welches günstige GPS für Linux-Nutze r?

[Sarah Hoffmann]

On Sun, Apr 18, 2010 at 02:23:52PM +0200, Thomas Reincke wrote:
 Sven Geggus schrieb:
  Manuel Reimer manuel.s...@nurfuerspam.de wrote:
  
  Was ich nun suche ist ein möglichst billiges GPS-Gerät
  
  Am günstigsten sidn reine Datenlogger. Wenn Du ein Gerät mit
  kartendarstellung haben möchtest dürfte der Garmin Etrex Legend HCx
  das günstigste Gerät sein. Straßenpreis rund 160 Euro.
 
 Achtung. Ich habe einen Qstarz-Logger. Eigentlich ein feines Teil. Aber 
 um die geloggten Tracks runterzubekommen muß ich nicht nur an einen 
 Windows-PC, für die Software sondern auch noch einen eigenen Treiber. 
 Und er Programmierer gehört an den Genitalien aufgehängt, denn die 
 Tracks kann ich nur als Admin auslesen.

Ich habe einen Qstarz BT-Q1200 und betreibe ihn nur unter Linux. 
Auslesen und konfigurieren geht mit Hilfe von mtkbabel über USB problemlos.
Ich kann das Teil wärmstes empfehlen.

Gruss

Sarah

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

Re: [Talk-de] Liste aller Grenzrelationen der Staaten

[Sarah Hoffmann]

On Mon, Oct 12, 2009 at 12:22:19AM +0200, Stephan Knauss wrote:
 Frederik Ramm wrote:
  Stephan Knauss wrote:
  select distinct (osm_id*-1) as id, name, name:en as name_en from 
  planet_osm_line where osm_id 0 AND admin_level='2'

Da musst du jetzt aber noch diejenigen Relationen herausfiltern,
die nur als Subrelationen gebraucht werden, also zum Beispiel
#51239 Deutschland - Schweiz.

 Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Oder 
 hat es bei mir im Laufe der Zeit mal den Import zerbröselt? Die DB 
 bekommt schon länger nur die Tages-Diffs.

Das ist normal. planet_osm_line enthält nur einfache Wege. Wenn
eine Relation zerstückelt ist, taucht jedes Teilstück einzeln
in planet_osm_line auf.

Gruss

Sarah

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

[Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Sarah Hoffmann]

Hallo,

wie einige vielleicht mitbekommen haben, stelle ich eine Karte mit
Wanderwegen der Schweiz zur Verfügung. Nach einigem Umbau des Renderings
ist diese Karte ab sofort weltweit verfügbar:

http://osm.lonvia.de/world_hiking.html

Das Ganze ist noch etwas experimentell, am Stil kann und wird sich in
den nächsten Wochen noch einiges ändern. Aber die Karte ist schon ganz 
brauchbar, um an den kommenden langen Winterabenden die vielen Löcher
in den Wanderrelationen zu reparieren und vielleicht mal etwas
Konistenz in die Klassifizierung zu bringen. (Sollten die ganzen
Jakobswege nicht alle network=iwn sein? Ich meine, mich zu 
erinnern, dass deren Ausschilderung ein EU-Projekt sei.)

Weitere Anmerkungen:

Die Karte wird täglich aktualisiert, es dauert aber bis zum späten
Nachmittag bis die Daten des Vortages verfügbar sind.

Die Implementierung des osmc:symbol-Tags ist noch nicht ganz vollständig,
und die Interpretation von ref-Tags folgt in den nächsten Tagen. Dazu eine
Frage: wäre es nicht sinnvoll die Liste der möglichen Werte des
osmc_symbol-Tags ins Wiki zu verlegen, damit Leute neue Werte einfacher
beschreiben können?

Die einzelnen Wegefarben wie im osmc:symbol-Tag beschrieben zu rendern,
ist in einem Overlay leider nicht möglich, weil die Zahl der verwendbaren
Farben begrenzt ist. Es gibt daher nur eine Unterscheidung nach network-Typ.

Der Rendering-Prozess ist so aufgesetzt, dass er für verschiedene Regionen
unterschiedliche Stile rendern kann. Zur Zeit nutze ich das nur, um das
Knoten-Wanderwegenetz der Schweiz speziell zu rendern, aber es wäre
interessant zu sehen, ob der Ansatz skaliert. Wenn es also andere
Regionen gibt, die eine Spezialbehandlung wünschen, Mail an mich.
Mehr dazu auch unter:
http://osm.lonvia.de/world_hiking/regional_de.html

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Sarah Hoffmann]

On Wed, Oct 21, 2009 at 05:36:08PM +0200, Werner Hoch wrote:
 Hallo Sarah,
 
 On Mittwoch, 21. Oktober 2009, Sarah Hoffmann wrote:
  wie einige vielleicht mitbekommen haben, stelle ich eine Karte mit
  Wanderwegen der Schweiz zur Verfügung. Nach einigem Umbau des
  Renderings ist diese Karte ab sofort weltweit verfügbar:
 
  http://osm.lonvia.de/world_hiking.html
 
 Super Darstellung.

Danke. Freut mich, wenn es gefällt.

 Könntest du nicht die Symbole vom Wiki aus dem wiki:symbol Tag 
 verwenden?
 
 Hier z.B. die Symbole der Wanderwege im Bodenseekreis:
 http://wiki.openstreetmap.org/wiki/Bodenseekreis#Rad-_und_Wanderwege

Ja, da sollte ich mich auf jeden Fall auch noch mit beschäftigen. Ich
sehe, dass das SVG-Dateien sind, da hält sich der Aufwand in Grenzen.
Bleibt nur noch die Frage, ob die Symbole auch bei einer Grösse von
15x15 Pixeln erkennbar sind.

Prinzipiell gebe ich aber Karl recht. Wo eine Stilisierung des Symbols mit
den Möglichkeiten des osmc:symbol-Tags möglich ist, sollte das auch
genutzt werden. Also, in deinem Fall sollten HW4-HW9 auf jeden Fall
auf das osmc:symbol-Tag abgebildet werden. Beim Franziskusweg würde
vermutlich ein schwarzes T auf weissem Grund tun (die Schrift darunter
würde man ohnehin nie sehen). Bei den anderen beiden wäre ein
Sondersymbol wohl schon ok.

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Sarah Hoffmann]

On Wed, Oct 21, 2009 at 07:59:30PM +0200, Mirko Küster wrote:
 http://osm.lonvia.de/world_hiking.html?zoom=11lat=51.30531lon=11.38827layers=TBT
 
 Da wäre noch ein kleines Problem. Einige Wege nutzen hier paralel den 
 gleichen Weg. Es wird aber immer nur ein Symbol gezeigt. Diese pralelen 
 Verläufe sieht man in der Karte nun leider nicht, manche Wege werden dadurch 
 gleich ganz unterschlagen. Wäre schön wenn sich das noch beheben ließe.

Das ist leider ein grundsätzliches Problem im Mapnik-Renderer. Um
es zu beheben, werde ich mir dessen Code ansehen müssen. Wird also
leider nicht von heute auf morgen passieren.

 Noch eine kleine Anregung. Hoverinfos und Route markieren. Wäre schön wenn 
 man eine Weg markieren könnte und dieser dann hervorgehoben wird. Zusätzlich 
 könnte man noch hinterlegte Infors wie Name, Länge und Comment einblenden.

Das wäre Phase 2 des Projektes: eine echt interaktive Karte mit der man 
auch Wanderungen planen kann. Ich habe da schon einige Ideen, aber die
Realisierung wird noch einige verregnete Wochenenden benötigen.

 Und noch ein altes und leidiges Problem. Ich weiß das es wahrscheinlich an 
 Openlayers liegt und der Kartenersteller vielleicht nichts für kann. Aber 
 auch diese Karte tut es unter Internet Explorer nicht.

Das habe ich schlicht und ergreifend vergessen, zu testen. Es war ein
CSS-Problem. Ich habe es so verändert, dass man zumindest etwas sieht.
(Getestet mit IE8. IE7 sollte theoretisch tun, darunter garantiert nicht.)
Ideal ist die Darstellung trozdem nicht. Für Hinweise, wie ich den IE
dazu bringe, die Höhe der Karte korrekt zu berechnen, bin ich dankbar.

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Sarah Hoffmann]

On Thu, Oct 22, 2009 at 12:41:05PM +0200, Steffen Wolf wrote:
 Hi Georg Feddern,
 
  Rotbarsch schrieb:
 
  osmc:symbol = black:black:white_diamond:2:white
 
  Hier wird die 2 (laut Beschreibung korrekt) auf das Symbol gerendert.  
  Haben wir auch eine Chance, sie dahinter zu bekommen?
 
  Habt ihr schon mal probiert,
  - statt dem Symbol white_diamond
  - ein Unicode-Zeichen als Text vor der 2 einzugeben?
 
  Je nach gewünschtem Symbol z.B. 25CA, 25C7 oder 2662.
 
 Ach, jetzt versteh ich das! Ich hatte schon auf der Wanderwegeseite nach
 Zeichen mit einer 2 auf dem Diamanten gesucht. Oder einer 2, die halb
 vom Diamanten verdeckt wird.

Ging mir genauso.

Die Lösung mit Unicode ist in diesem Fall tatsächlich die einzige
funktionierende Lösung. Ich persönlich würde aber hier eher
die Lösung osmc:symbol = black:black:white_diamond_line:2:white
wählen. Sollte auf beiden Karten gut aussehen.

 So also: ???2 ???2 ???2
 
 Es koennte u.U. dem Renderer Probleme bereiten, wenn die verwendete
 Schrift nicht die Zeichen umfasst. Dann hilft vielleicht noch ein
 Leerzeichen oder gar ein nbsp; vor der 2.

Tut mir leid. Von solchen billigen Tricks lässt sich der Renderer nicht
beeindrucken. ;) Leerzeichen vor und nach dem Text werden gnadenlos
gelöscht (aus guten Grund, ein Leerzeichen ist kein Tool zum Ausrichten
von Text). Wenn nbsp; verwendet wird, wird der Text insgesamt zu lang
und wird gar nicht mehr dargestellt. Der Textteil im osmc:symbol darf
maximal 3 Zeichen haben. (Alles natürlich auf meine Karte bezogen.) 

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay jetzt weltweit verf ügbar

[Sarah Hoffmann]

On Thu, Oct 22, 2009 at 07:26:30PM +0200, Karl Eichwalder wrote:
 Hier gibt es einen rautenweg (allerdings ist da was kaputt):
 
 http://osm.lonvia.de/world_hiking.html?zoom=14lat=51.35336lon=9.41579layers=TBT
 
 Das habe ich ungefaehr so eingegeben:
 
 black:black: :???:white
 

Ich bin kein grosser Freund dieser ganzen Unicode-Magie. Es ist praktisch
unmöglich vorauszusagen, was da bei Rendern herauskommt. Nur weil es jetzt
vielleicht auf der einen Kartendarstellung passt, kann es die nächste
schon komplett zerstören. Für deinen Weg gibt es bereits das passende 
osmc:symbol-Tag:

black:black:white_diamond_line

Genauso für Relation 87543. Da gibt es:

black:white:white_turned_T

Die entstehenden Symbole sind viel kontrastreicher, als die schmalen
Dinger, die aus dem Font gerendert werden.

Und in Relation 297122 fehlt die Textfarbe. Was dabei herauskommt ist
allerdings wirklich ein Bug. Der Text sollte gar nicht gerendert werden.


 Wahrscheinlich werde ich es aber auf
 
 black:white: :???:black
 
 unstellen.  Frueher wurden alle weissen markierung auf den karten
 schwarz wiedergegeben und das war prima zu erkennen und jeder hat das
 verstanden.

Ich wäre eher dafür zu mappen, was man in der freien Wildbahn auch sieht.
Wenn eine Karte weisse Markierungen invertieren möchte, kann sie das relativ
einfach selber tun.

Gruss

Sarah

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

Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)

[Sarah Hoffmann]

On Tue, Nov 03, 2009 at 12:49:39AM +0100, Tobias Knerr wrote:
  wenn das ganze dagegen folgendermassen getaggt ist:
  
amenity = recycling
recycling:batteries = yes
recycling:glass = yes
recycling:paper = yes
recycling:cars = no
  
  ist das wesentlich aufwendiger zu verarbeiten,
 
 Für welche Zwecke?
 
 Bei den Beispielen, die mir so einfallen, kann ich da keinen
 Zusatzaufwand erkennen. Einfacher Fall: Ich will wissen, ob ein Objekt
 eine Recyclingstelle für (unter anderem) Glas ist.
 
 Pseudocode yes/no:
 
 wenn objekt.wertVon(amenity) ist recycling
  und objekt.wertVon(recycling:glass) ist yes
 dann ...
 
 Pseudocode Semikolon:
 
 wenn objekt.wertVon(amenity) ist recycling
  und objekt.wertVon(recycling).trenneAn([whitespace]*;)
   .enthält(glass)
 dann ...
 
 Sieht ähnlich aus. Wenn überhaupt ist die Notwendigkeit der Trennung des
 Wertes noch ein zusätzlicher Aufwand.

Leider funktioniert das in der Realität nicht wirklich, weil die meisten
amenity = recycling ohne Zusatztags daherkommen. Das heisst, damit deine
Verarbeitung einigermassen robust ist, möchtest du zusätzlich alle
amenities = recycling finden, die ohne Material-Infos getaggt sind.
Mit Simikolon-Notation ist das programmtechnisch ganz einfach zu
lösen, mit yes/no-Notation wird das ganze extrem aufwändig, weil du
immer alle Tags des Objektes scannen musst.

Oder versuche mal, mit Hilfe von osm2pqsql/Mapnik, eine Karte zu
erzeugen, die tagesaktuell Recycling-Stellen mit den entsprechenden Untertypen
anzeigt. Dort muss beim Import in die Postgresql für jeden
recycling:..-Tag eine eigene Spalte in der DB-Tabelle angelegt
werden. Das heisst, jedes Mal, wenn du eine neue Art von Recycling-
Material anzeigen willst, musst du die Datenbank komplett neu importieren
Das dauert je nach Rechenpower zwischen 2 Tagen und einer Woche.
In der Semikolon-Notation müsste man lediglich eine neue Rendering-
Regel einfügen.

Es ist einfach müssig, Tagging-Schemen aufgrund irgendwelcher Software-
Anforderungen auszuwählen. Dafür gibt es viel zu viele Anwendungs-
möglichkeiten der OSM-Daten, die alle anders funktionieren.
Die Software muss sich da einfach an das existierende anpassen.
Es wäre vermutlich recht einfach, osm2psql so umzuprogrammieren,
dass es mit recyling:...-Tags zurechtkommt, aber genauso hat
der OSM-Composer nicht die geringsten Probleme damit, das
osmc:symbol-Tag zu verstehen, dass mit Doppelpunkt-getrennten
Werten daherkommt.

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay Hillshading

[Sarah Hoffmann]

Hallo,

 ich habe mir gerade die Wanderkarte
 
 http://osm.lonvia.de/world_hiking.html
 
 angeschaut. Dabei ist mir aufgefallen, dass das Hillshading bei mir nicht 
 angezeigt wird. Ist da gerade was kaputt, oder liegt das an meinem Browser? 
 (Firefox 3.5.4 unter Linux)
 Auf http://www.osm-wms.de/ funktioniert das Hillshading.

Danke für den Hinweis. Das ist kein Fehler deines Browsers. Da scheint es 
ein komplizierteres Problem zu geben. Bis ich die Ursache gefunden habe, 
habe ich den Hillshading-Layer vorerst deaktiviert. Update folgt.

Gruss

Sarah

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

Re: [Talk-de] Topo-Layer der Geofabrik

[Sarah Hoffmann]

Hallo Nop,

  Evtl. kannst du den Topo-Layer von http://topo.geofabrik.de/ verwenden.
 
 Die dürfte nicht passen. Die Relief-Layer der Uni Bonn ist transparent und 
 liegt über der gesamten Karte. Das Relief von der Wanderkarte ist
 undurchsichtig und liegt unter der Karte, damit Straßen, POIs usw. nicht mit
 Reliefschatten überdeckt werden.

Das hätte ich auch vermutet, aber ich habe mir erlaubt, es trotzdem mal
auszuprobieren. Wie sich herausstellt, sind die Relief-Tiles tatsächlich
recht brauchbar, wenn man sie mit hoher Transparenz über die Mapnik-
Karte legt. Sie sind auch insofern eine interessante Alternative, als
dass sie zusätzlich Höhenlinien bieten.

Insofern würde ich mich freuen, wenn ich die Tiles als alternativen Relief-Layer
anbieten könnte. Was meinen du und Frederik (als Serverbetreiber) dazu?
Wäre das okay?

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay Hillshading

[Sarah Hoffmann]

On Mon, Nov 09, 2009 at 04:06:33PM +0100, Stephan Olbrich wrote:
 Hallo,
 
 ich habe mir gerade die Wanderkarte
 
 http://osm.lonvia.de/world_hiking.html
 
 angeschaut. Dabei ist mir aufgefallen, dass das Hillshading bei mir nicht 
 angezeigt wird. Ist da gerade was kaputt, oder liegt das an meinem Browser? 
 (Firefox 3.5.4 unter Linux)
 Auf http://www.osm-wms.de/ funktioniert das Hillshading.

Fehler gefunden, ich hatte etwas im JavaScript-Code kaputt gemacht.

Der Hillshading-Layer ist jetzt wieder da, er muss allerdings
explizit aktiviert werden, um die Ladezeiten nicht unnötig zu erhöhen.

Gruss

Sarah

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

Re: [Talk-de] AddGeometryColumn() War: Re: Ab stände zu POIs visualisieren?

[Sarah Hoffmann]

On Thu, Nov 12, 2009 at 07:06:21PM +0100, Stefan Schwan wrote:
 Als absoluter Anfänger habe ich das mal ausprobiert: Ich bekomme von 
 Mapnik so nur eine Fehlermeldung:
 
 UserWarning: PostGIS Driver Error: Geometry column not specified or 
 found in geometry_columns table: 'postboxareas'. Try setting the 
 'geometry_field' parameter or adding a proper geometry_columns record 
 (encountered during parsing of layer 'postboxarealayer')
 
 Ich habe inzwischen herausbekommen, das die Funktion addgeometrycolumn 
 hier Abhilfe schaffen soll, und die neue Tabelle mit der fehlenden 
 Spalte ausrüstet und sie der Tabelle  geometry_columns einträgt.
 
 Ich habe also versucht, nach 
 
 CREATE TABLE postboxareas AS SELECT buffer(way, 500) FROM 
 planet_osm_point WHERE amenity='post_box';
 
 die Abfrage
 
 SELECT AddGeometryColumn ( 'postboxareas', 'geom', 900913, 'POLYGON', 2 );
 auszuführen.

Das fügt eine zusätzliche Geometrie-Spalte in deine Tabelle. Das
ist nicht, was du willst, sondern du musst Mapnik mitteilen, dass
deine einzige Spalte die Geometry enthält. Diese Info holt sich
Mapnik aus der Tabelle geometry_columns. Dort musst du einen
Eintrag hinzufügen.

Es ist besser, wenn du deiner Spalte einen expliziten Namen gibst:

CREATE TABLE postboxareas AS SELECT buffer(way, 500) as geom FROM
planet_osm_point WHERE amenity='post_box';

Dann die Info in die geometry_columns-Tabelle einfügen:

INSERT INTO geometry_columns VALUES('', 'public', 'postboxareas', 'geom', 2, 
900913, 'POLYGON');

Gruss

Sarah

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

Re: [Talk-de] Lonvia-Karte drucken?

[Sarah Hoffmann]

Hallo,

On Wed, Nov 18, 2009 at 04:53:50PM +0100, Karl Eichwalder wrote:
 Kennt jemand einen Trick, wie man Ausschnitte der
 http://osm.lonvia.de/world_hiking.html drucken kann?

 Alternativ würde es mir auch helfen, wenn ich den Hiking-Path-Overlay in
 den Maemo-Mapper (N810) hinein bekäme.

Weisst du, ob das Overlaying im Maemo-Mapper inzwischen gut funktioniert?

Testwise kannst du versuchen einen Layer mit folgender URL einzurichten:
http://osm.lonvia.de/hiking/%0d/%d/%d.png
(Für die Layers gibt es einen Extra-Button unter Manage Repositories)

Aber bitte nicht versuchen, dann den ganzen Planeten herunterzuladen.
Ich habe hier ein Programm liegen, dass aus einer Menge Tiles eine DB für
den Maemo-Mapper erstellt. Der Gesamtsatz an Tiles ist mit 1.5GB etwas
gross, aber für Teilgebiete könnte ich vielleicht Auszüge anbieten. Ich
schau mir das mal an. Welches Gebiet interessiert dich genau?

Gruss

Sarah

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

Re: [Talk-de] Wanderwege-Overlay Hillshading

[Sarah Hoffmann]

On Wed, Nov 18, 2009 at 05:01:05PM +0100, Karl Eichwalder wrote:
 Sarah Hoffmann lon...@denofr.de writes:
 
  Der Hillshading-Layer ist jetzt wieder da, er muss allerdings
  explizit aktiviert werden, um die Ladezeiten nicht unnötig zu erhöhen.
 
 Gut sieht's aus, aber bei mir ist der Hillshading-Layer gleich aktiv
 (vielleicht liegt das an einem Alt-Cookie?).

Hier geht es, sogar mit dem IE. Hast du die Karte vielleicht über
einen Permalink aufgerufen (also mit layers irgendwo in der URL)?

 Das Relief (topo) ist auch sehr schon und nutzlich.  Es sollte, finde
 ich, nur etwas kontrasreicher sein.  Ich wurde fur die Linien ein
 Schwarz-Braun nehmen und die Hohenangaben unbedingt richtig tiefschwarz
 anzeigen; wenn das stort, kann man den Layer ja temporar abschalten.
 
 Ich find's zudem nicht ganz optimal, dass durch diesen Layer ein
 Grauschleier uber die gesamte Karte gelegt wird.  Ist das technisch
 bedingt?

Das ist leider tatsächlich dadurch bedingt, dass ich es mit so
hoher Transparenz über die Karte lege. Das Relief wurde eben nicht
als Overlay konzipiert. Mehr Transparenz: weniger
Grauschleier, weniger lesbare Höhenangaben. Weniger Transparenz:
besser sichtbare Höhenangaben, mehr Grauschleier.

Ich hoffe darauf, dass Colins Lösung irgendwann serienreif wird.
Die ist als Overlay konzipiert und deshalb besser geeignet.

Gruss

Sarah

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

Re: [Talk-de] Lonvia-Karte drucken?

[Sarah Hoffmann]

On Thu, Nov 19, 2009 at 05:45:54PM +0100, Karl Eichwalder wrote:
 Karl Eichwalder k...@gnu.franken.de writes:
 
  Weisst du, ob das Overlaying im Maemo-Mapper inzwischen gut funktioniert?
 
  Um ehrlich zu sein, ich habe mit Maemo-Mapper seit ein paar Monaten
  nichts mehr gemacht (weil ich jetzt ein Garmin habe).  Aber manchmal
  sehne ich schon zurück zu der schönen Kartenansicht auf dem N810 und ich
  würde es gern mal wieder mit deiner Karte versuchen.
 
 Das Overlaying funktioniert zumindest mit der von dir angegebenen URL
 sehr gut (ich hoffe, ich habe nicht zu viel Traffic gerade verursacht).
 Es ist nur etwas umstandlich, den Layer ein- und auszuschalten.

Keine Sorge, solange du dich nur auf der Karte bewegst, kannst du nicht
zuviel Traffik erzeugen. 

 Und nicht nur das, leider scheint man ein Layer nicht aus 
 einer gespeicherten Datenbank lesen zu konnen.  So ein Layer 
 wird offensichtlich immer on-the-fly aus dem Internet hinzugeladen; er
 cachet das leider nicht.   

Jetzt habe ich das mal probiert. Er cacht das schon, wenn du ein
entsprechendes Cache-File angibst. Allerdings kommt er nicht damit klar,
dass die Karte lückenhaft ist. Das heisst, dort wo es keine Wanderwege
gibt, liefert der Server einen 404-Error zurück anstatt eines leeren Teils.
Die Browser wissen damit etwas anzufangen, aber MaemoMapper scheint die
Teile sofort noch einmal laden zu wollen. Sobald du Auto-Download ausschaltest
ist alles gut.

 Das ist super.  Ich hoffe, ich kann am Wochenende so ein paar Routen
 nachtragen.  Jetzt beschwert er sich leider mal wieder uber Low
 Memory...

Soetwas habe ich befürchtet. Kann aber am Auto-Download gelegen haben.

Ich habe dir jetzt mal eine Offline-DB von Hessen erzeugt. Sie geht nur
bis Zoom 14, aber als Übersicht sollte es schon mal gehen:

http://osm.lonvia.de/maemo-mapper/wanderwege_hessen.db (etwa 30MB)

Lade die Datei herunter und kopiere sie auf dein N810. In der Layer-
Beschreibung lässt du dann das URL-Feld komplett leer und trägst die 
Datei unter Cache-File ein. Auto-Download ist dann nicht mehr kritisch,
ich würde es aber trotzden auslassen.

Leider ist mein Programm zur DB-Erstellung (noch) nicht zur Erstellung von
Kartenausschnitten geeignet, da muss ich noch ein paar Stunden Programmier-
arbeit hineinstecken, bevor ich regelmässig aktualisierte Ausschnitte
anbieten kann. 

Gruss

Sarah

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

Re: [Talk-de] Doppelte Nodes - verdoppelung in zwei Wochen?!

[Sarah Hoffmann]

On Mon, Nov 23, 2009 at 02:27:57PM +0100, Thomas Ineichen wrote:
 Hallo zusammen,
 
 Ich lasse gelegentlich Gary86s Doublenode-Script[1] über die Schweiz 
 laufen. Hier die Ergebnisse:
 
 DatumDoppelte Nodes
 04.09.2009  4832
 01.10.2009  3069
 01.11.2009  4256
 05.11.2009  4256
 07.11.2009  4258
 11.11.2009  4048
 13.11.2009  4069
 14.11.2009  4058
 19.11.2009  7384
 20.11.2009  7390
 22.11.2009  8905
 
 Wie man sieht, hat sich die Zahl vom 14.11. bis heute mehr als verdoppelt! 
 Wie finde ich am einfachsten heraus, wer/was das verursacht haben könnte? 
 Am Script wurde in der Zwischenzeit nichts verändert.
 
 
 Leider bricht bei mir* OSMdiff[2] mit out of memory ab.
 
 
 Die entsprechenden Planet-Extrakte sowie die Script-Reporte habe ich auf 
 meinem Server abgelegt:
 
 http://osm.t-i.ch/tmp/

Ich habe dir mal schnell ein Diff zwischen den beiden HTMLs vom 14. und
20., sowie 20. und 23., gemacht:

http://osm.lonvia.de/stuff/nodediff_14_20.txt
http://osm.lonvia.de/stuff/nodediff_20_23.txt

Weitere Nachforschungen überlasse ich dir.

(Falls es interessiert, unter Linux einfach die Holzhammermethode:

grep 'http://www.openstreetmap.org/browse/node' 2009-11-14-double.html | grep 
-o '[[:digit:]]\+' | sort -u  14.out
grep 'http://www.openstreetmap.org/browse/node' 2009-11-20-double.html | grep 
-o '[[:digit:]]\+' | sort -u  20.out
diff 14.out 20.out

)

Gruss

Sarah

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

Re: [Talk-de] mapnik und relationen

[Sarah Hoffmann]

On Mon, Nov 30, 2009 at 06:47:35PM +0100, Stephan Olbrich wrote:
 Hallo zusammen,
 
 gibt es irgendwo eine Anleitung, wie ich mapnik dazu bewegen kann Relationen 
 zu rendern? (Und was ich alles beim Import der Daten in die Datenbank 
 beachten 
 muss, etc.)

Es kommt darauf an, was du machen willst. Wenn du einfach die Wege
rendern willst, die in einer Relation enthalten sind und
solange es Relationen sind, die ein type-Tag haben, kannst du osm2pgsql
benutzen.[1] (Zumindest laut Sourcecode, probiert habe ich das bisher nur
mit type=route-Relationen.)

Einfach in default.style die entsprechenden Tags eintragen, die
du von der Relation brauchst. Die Relationen finden sich dann wie alle
anderen Wege in planet_osm_line und das Rendern funktioniert genauso
wie für normale Wege. Zu beachten ist höchstens noch, dass es für eine
Relation mehrere Einträge geben kann, nämlich dann, wenn es Lücken gibt.
Geschachtelte Relationen funktionieren nicht.

Gruss

Sarah


[1] http://wiki.openstreetmap.org/wiki/DE:Mapnik?uselang=de

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

Re: [Talk-de] mapnik und relationen

[Sarah Hoffmann]

On Tue, Dec 01, 2009 at 07:08:29PM +0100, Stephan Olbrich wrote:
  On Mon, Nov 30, 2009 at 06:47:35PM +0100, Stephan Olbrich wrote:
   Hallo zusammen,
  
   gibt es irgendwo eine Anleitung, wie ich mapnik dazu bewegen kann
   Relationen zu rendern? (Und was ich alles beim Import der Daten in die
   Datenbank beachten muss, etc.)
  
  Es kommt darauf an, was du machen willst. Wenn du einfach die Wege
  rendern willst, die in einer Relation enthalten sind und
  solange es Relationen sind, die ein type-Tag haben, kannst du osm2pgsql
  benutzen.[1] (Zumindest laut Sourcecode, probiert habe ich das bisher nur
  mit type=route-Relationen.)
  
  Einfach in default.style die entsprechenden Tags eintragen, die
  du von der Relation brauchst. Die Relationen finden sich dann wie alle
  anderen Wege in planet_osm_line und das Rendern funktioniert genauso
  wie für normale Wege. Zu beachten ist höchstens noch, dass es für eine
  Relation mehrere Einträge geben kann, nämlich dann, wenn es Lücken gibt.
  Geschachtelte Relationen funktionieren nicht.
 
 Genau sowas suche ich. Könntest Du mir als Beispiel Deinen default.style und 
 Mapnik-Renderregeln schicken? (Oder die relevanten Ausschnitte)

Die Dateien, die ich für die Wanderkarte benutze, findest du hier:

http://osm.lonvia.de/dev/default.style
http://osm.lonvia.de/dev/hiking.xml

Letzteres ist aber mit Vorsicht zu geniessen, weil ich die Daten aus der
Datenbank vorverarbeite und in einer eigenen Tabelle abspeichere. Aber das
Prinzip ist das gleiche. Also, wenn du zum Beispiel alle nationalen
Wanderwege rendern willst, sieht der einfachste Mapnik-Stil dazu so aus:

Map bgcolor=#FF srs=+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +  
lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over
Style name=nwn_big
Rule
  LineSymbolizer
CssParameter name=stroke#152eec/CssParameter
CssParameter name=stroke-width1.5/CssParameter
  /LineSymbolizer
/Rule
/Style
Layer name=nwn_big status=on
   Datasource
   Parameter name=typepostgis/Parameter
 Parameter name=port5432/Parameter  
 Parameter 
name=estimate_extentfalse/Parameter  
 Parameter 
name=extent-20037508,-19929239,20037508,19929239/Parameter
 Parameter name=dbnameplanet/Parameter
 Parameter name=userosm/Parameter
 Parameter name=table(select way from 
planet_osm_line where nwn is not null) as ways/Parameter
/Datasource
StyleNamenwn_big/StyleName
/Layer
/Map

(Anmerkung: für die Spalten nwn, rwn, lwn gibt es hart-kodierte Regeln
 im Sourcecode, wie diese aus dem network-Tag zu entnehmen sind. Das ganze
 ist historisch motiviert, weil es Zeiten gab, wo Wander- und Radrouten
 nicht in Relationen, sondern mit einem Tag am Weg gekennzeichnet wurden.
 Du kannst natürlich auch das network-Tag auswerten, musst es dann aber
 in default.style nachtragen.)

Für weitere Experimente empfehle ich die Mapnik-Style-Referenz
http://trac.mapnik.org/wiki/XMLConfigReference
zu studieren und einen Blick in die XML-Style-Datei der Hauptkarte zu
werfen.

Gruss

Sarah

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

Re: [Talk-de] Fahrthäufigkeit bei Buslinien

[Sarah Hoffmann]

On Wed, Dec 02, 2009 at 08:09:08PM +0100, Karl Eichwalder wrote:
 Stephan Wolff s.wo...@web.de writes:
 
  Die URL des Fahrplans aufzunehmen ist grundsätzlich eine gute Idee.
  Sie ersetzt die anderen Angaben aber nicht, da sich der Fahrplan nur bei 
  Onlinezugang vom PC und (mit Einschränkungen) am Mobiltelefon lesen 
  lässt. Unterschiedliche Kartendarstellungen je nach Fahrdichte oder 
  Informationen im Garmin-GPS sind damit allein nicht möglich.
 
 Wie schon gesagt, diese unterschiedliche Kartendarstellungen sehen
 hubsch aus, nutzen aber im Alttag nichts.  Das ist so etwas, was
 Verwaltungsfuzzis und andere Sesselpupser erfreut ;)

Du musst nicht von dir auf die Allgemeinheit schliessen. In der Schweiz,
wo jedes öffentliche Verkehrsmittel (vom Zug Ìber den Bus bis hin zum
Schiff) einen mehr oder weniger dichten Taktfahrplan hat und alles so
integriert ist, dass AnschlÌsse immer gewÀhrt sind, ist so eine Karte
in der Tat extrem nÃŒtzlich. Man _kann_ hier wandern gehen und den Endpunkt
der Wanderung aufgrund der Frequenz der Busse spontan festlegen.

Ganz Àhnlich wÀre so eine Karte fÌr deutsche GrossstÀdte zu gebrauchen.
Wenn man ein Hotel in Frankfurt sucht, dann ist dasjenige, dass an einer
Buslinie mit 10-min-Takt liegt, demjenigen, dass an einer Buslinie mit
Stundentakt liegt, vorzuziehen.

Ob diese Informationen nun in die OSM-Datenbank sollten oder nicht, ist
ein anderes Problem. Aber ich finde, dass Stephans letzter Vorschlag
wirklich einfach ist, und die Datenbank wohl kaum ÌbermÀssig aufblÀht.
Und wenn er sich die Arbeit machen möchte, und das eintragen,
dann nur zu. Ich bin jedenfalls gespannt, wie es funktioniert.

Gruss

Sarah

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

Re: [Talk-de] Fahrthäufigkeit bei Buslinien

[Sarah Hoffmann]

On Thu, Dec 03, 2009 at 04:32:08AM +0100, Karl Eichwalder wrote:
 Sarah Hoffmann lon...@denofr.de writes:
 
  Du musst nicht von dir auf die Allgemeinheit schliessen. In der Schweiz,
  wo jedes öffentliche Verkehrsmittel (vom Zug Ìber den Bus bis hin zum
  Schiff) einen mehr oder weniger dichten Taktfahrplan hat und alles so
  integriert ist, dass AnschlÌsse immer gewÀhrt sind, ist so eine Karte
  in der Tat extrem nÃŒtzlich. Man _kann_ hier wandern gehen und den Endpunkt
  der Wanderung aufgrund der Frequenz der Busse spontan festlegen.
 
 Ich denke, man wird zumindest noch wissen wollen, wann der letzte Bus
 fährt.  Oder wann der letzte Bus fährt, der noch gewährleistet, dass man
 einen passenden Zug erreicht.  Gibt es keine wochentäglichen und keine
 jahreszeilichen Unterschiede?  Wie soll das alles in einer Linie
 abgebildet werden?  Gut, vielleicht geht das sogar.

Der Sonntagsfahrplan ist auf den Buslinien etwas ausgedünnt, aber nicht
überall und auch nicht so, dass er unbrauchbar wird. Für die erste und
letzte Fahrt gilt als Faustregel, dass man zwischen 6 und 6 losfahren
kann und noch bis in die Städte des Mittellands (Zürich, Bern, Basel)
kommt. 

 Wahrscheinlich fahren busse in der Schweiz einfach so häufig und
 regelmäßig über den Tag verteilt, dass es geht.  Wird wirklich stur nach
 Takt gefahren?  Wenn es 4 Verbindungen am Tag gibt und die erste um 6 und
 die letzte um 18 Uhr geht, dann gehen die 2 anderen Verbindungen um 10
 und um 14 Uhr?

Nein, es gibt zwei am Morgen und zwei am Abend, also gegen 6, 8, 16, und 
17 Uhr. Aber auch das ist wieder relativ konstant in der ganzen Schweiz.
Und der Sinn einer Karte mit Fahrthäufigkeiten wäre ja gerade der, diese
Linien zu erkennen und vielleicht doch mal den Fahrplan zu konsultieren
oder eben zu einer anderen Haltestelle zu gehen.

 Ist auch wieder wahr.  Ich find's schon ausreichend, wenn ich sehen
 kann, wo es überhaupt ÖPNV gibt.  Und eine Unterscheidung nach
 Wochentagen und Jahreszeiten wäre sehr hilfreich.

Stimmt, ich würde bei operating_hours auch Werte wie summer, winter,
schooldays erlauben, dann muss man die Daten nicht jedes Jahr ändern.

Gruss

Sarah

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

Re: [Talk-de] Jakobswege: HIKING oder PILGRIMGE in den Relationen

[Sarah Hoffmann]

On Thu, Dec 03, 2009 at 10:51:12AM +0100, Andre Joost wrote:
 Martin Simon schrieb:
  Am 3. Dezember 2009 09:23 schrieb Jan Tappenbeck o...@tappenbeck.net:
   Moin !
 
  Um eine Diskussionsgrundlage zu haben bat ich Flohoff einmal seine
  OSM-Datenbank nach den Relationen mit dem Begriff JAKOBSWEG abzufragen
  um einmal eine Übersicht der verwendeten Klassifizierungen zu bekommen:
 
  Gesamtzahl: 54 Relationen#
  FOOT = 16
  HIKING = 21
  PILGRIMAGE = 17

Das sind aber nur die deutschen Wege. Ich finde route=pilgrimage
28x in der Datenbank, darunter auch drei komische:
 27485 route=pilgrimage, foot, bicycle
152746 route=bicycle;pilgrimage
299491 route=bicycle;pilgrimage

 
 Wobei ich anmerken möchte, daß die Jakobswege in NRW in der Natur mit 
 Pilgerweg beschriftet sind.  Ich habe die in OSM daher mit 
 Jakobs-Pilgerweg getaggt. Der Suchbegriff Jakobsweg allein ist also 
 eventuell nicht umfassend.
 Foot/hiking ist für mich sinnvoller als Pilgrimage, weil die Renderer 
 das jetzt schon darstellen, pilgrimage wird nirgendwo ausgewertet.

Am Renderer würde ich das nicht festmachen. Dass die Wege nicht auf
meiner Wanderkarte erscheinen, hat mehr technische Gründe: 
route=pilgrimage umfasst i.A. nicht nur den Weg selber, sondern
auch Kirchen (siehe http://wiki.openstreetmap.org/wiki/Camino_de_Santiago).
Um die eigentlichen Wanderwege darstellen zu können, muss also unbedingt 
die Rolle eines jeden Wegs in der Relation ausgewertet werden. Das ist 
in Planung, geht aber zur Zeit noch nicht.

Aus Renderersicht würde ich natürlich trotzdem 
route=hiking
pilgrimage=yes
voziehen, weil es jetzt schon einen Wildwuchs an Tags für Wanderwege
(foot/hiking/walking) gibt. Allerdings würden dann die Pilgerkirchen
verloren gehen. Alternative wäre, beide Relationstypen zu behalten.
Dann zurerst den Pilgerweg selbst in eine route=hiking-Relation und
dann diese Relation zusammen mit den Pilgerkirchen in eine
route=pilgrimage-Relation zu packen.

 Ich schon. Ausserdem als network=iwn, weil das Ziel ja im Ausland liegt ;-)

Wikipedia hat mir inzwischen erzählt, dass die verschiedenen Wege
verschiedene Wichtigkeit haben. Sollte man das irgendwie abbilden?

Gruss

Sarah

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

Re: [Talk-de] Import von Planet.osm?

[Sarah Hoffmann]

Hallo,

On Mon, Dec 14, 2009 at 11:53:01PM +0100, Florian Heer wrote:
 Hi!
 
 Von euch hat doch bestimmt jemand Erfahrung damit, was der import eines 
 kompletten Planet-Files so an Resourcen braucht.
 1. Postgres-Datenbank: wieviel Platz auf der Platte brauche ich für ein 
 aktuelles Planet-file?
 2. Wie lange dauert so ein Import per osmosis? Ja, klar, kommt auf den 
 Rechner an, aber erfahrungsgemäß?
 
 Viele Grüße, Florian

Ich habe den Planeten kürzlich auf einer Dual-Core-CPU mit
2GB RAM in 30 Stunden mittels osmosis importiert. Das war allerdings auch
ohne Erstellung von bbox und linestrings. Ein Tagesupdate braucht ca.
2 Stunden. Platzverbrauch in dieser Version ca. 190 GB.

Der Import per osm2pgsql dauert auf dem gleichen Rechner 3-4 Tage bei
ca. 100GB Platzverbrauch. (Slim-Mode) Das Tagesupdate ist
hier 8-9 Stunden beschäftigt.

Gruss

Sarah

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

Re: [Talk-de] osmosis schema mit mapnik nutzen Was: Import von Planet.osm?

[Sarah Hoffmann]

On Tue, Dec 15, 2009 at 01:09:08PM +0100, Florian Lohoff wrote:
 On Tue, Dec 15, 2009 at 11:59:59AM +0100, Peter Körner wrote:
   Ich habe den Planeten kürzlich auf einer Dual-Core-CPU mit
   2GB RAM in 30 Stunden mittels osmosis importiert. Das war allerdings auch
   ohne Erstellung von bbox und linestrings. Ein Tagesupdate braucht ca.
   2 Stunden. Platzverbrauch in dieser Version ca. 190 GB.
   
   Der Import per osm2pgsql dauert auf dem gleichen Rechner 3-4 Tage bei
   ca. 100GB Platzverbrauch. (Slim-Mode) Das Tagesupdate ist
   hier 8-9 Stunden beschäftigt.
  
  Die osmosis-Version ist dann aber nicht für die verwendung mit mapnik 
  geeignet, oder?
 
 Jein - Das kann man so pauschal nicht sagen - Wenn du das standard mapnik
 osm.xml nehmen willst - NEIN - Auch ist das osmosis schema nicht so wirklich
 darauf optimiert. Mapnik braucht einfach eine tabelle mit einer geometry
 column - point, linestring und irgendwelchen metadaten was das eben sein soll.
 Mit entsprechenden regeln kann mapnik das dann malen.
 
 Nichtsdestotrotz benutze ich mapnik mit dem osmosis schema um gewisse
 dinge zu rendern - Ist nicht optimal und relativ langsam - aber man
 kann zur not auch das osmosis schema nehmen (Und ein paar views dranstricken
 damit da wa mapnik interpretierbares rauskommt)
 
 Hier ein Beispiel:
 
 drop view powerlineview;
 create view powerlineview AS
 SELECT ways.id,
 voltage.v as voltage,
 ways.linestring as geom
 fromways left outer join (
 select way_id,v from way_tags
  where k='voltage') voltage on ( ways.id = 
 voltage.way_id ),
 way_tags wt
 where   wt.k = 'power'
 and wt.v = 'line'
 and wt.way_id = ways.id;

Diese Anfrage stellst du aber nicht auf einer Datenbank, die den kompletten
Planeten enthält, oder? Wenn ich den SELECT-Teil auf meinem 
(zugegebenermassen etwas schwachbrüstigen) Rechner laufen lasse, braucht
die Anfrage knapp 15 Minuten. (Das ist natürlich immernoch wesentlich
günstiger als ein 8-Stunden-osm2psql-Tagesupdate, weswegen ich gerade
in diese Richtung experimentiere.)

Gruss

Sarah


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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote:
 Chris-Hein Lunkhusen schrieb:
  Hi,
  ich sehe immer öfters Wegweiser
  
  http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost
  
  die mit bicycle=yes getaggt sind.
 
 könnten glatt von mir sein ;-)
 
  
  Im Proposal kann ich da nichts zu finden, wieso ist das
  in JOSM als Option eingebaut (Dargestellte Routen für
  Radfahrer) ?
  
 
 Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die 
 guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 
 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht 
 dargestellt, aber was nicht ist kann ja noch werden...

Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;)

Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist
für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches
Tag, die Bedeutung nicht einfach einschränkt, sondern verändert:
ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit 
bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser.

Gruss

Sarah

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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

On Tue, Dec 22, 2009 at 10:24:14AM +0100, André Riedel wrote:
 Am 22. Dezember 2009 09:47 schrieb Sarah Hoffmann lon...@denofr.de:
  On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote:
  Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die
  guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14
  bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht
  dargestellt, aber was nicht ist kann ja noch werden...
 
  Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;)
 
  Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist
  für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches
  Tag, die Bedeutung nicht einfach einschränkt, sondern verändert:
  ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit
  bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser.
 
 information=guidepost heißt in erster Hinsicht, dass es ein Wegweiser
 ist und dich unterstützen soll, den Weg zu deinem Ziel zu finden oder
 auf der Route zu bleiben. Orientieren kannst du dich an allen, als
 Wanderer wirst du dich aber vornehmlich an den hiking=yes Wegweisern
 orientieren, als Fahrradfahrer vornehmlich an bicycle=yes und als
 Mountainbiker an allen beiden. Wenn ein Wegweiser beides anzeigt um so
 besser.

Ja, so ist das logisch, aber eben nicht die Praxis. Zumindest in der
Schweiz wurden bis zum Auftauchen der Unterklassifizierungen in JOSM
praktisch nur Wanderwegweiser eingetragen, eben weil das ursprüngliche
Proposal nur auf Wanderwegweiser abziehlte. Deshalb kann man wirklich
davon ausgehen, dass Wegweiser ohne genaue Klassifizierung Wanderweg-
weiser sind. Ich gehe davon aus, dass das in Deutschland ähnlich ist.

Das ist nicht weiter tragisch, muss man aber eben beim Kartenzeichnen
beachten, denn da interessiert der Ist-Zustand. Mit der Zeit wird sich 
das sicherlich so entwickeln, dass die meisten Wegweiser eine
Unterklassifizierung haben werden und das Problem hat sich erledigt.
Insofern würde ich die Option im JOSM jetzt auch einfach drin lassen.
Jetzt noch eine zweite Variante für die Unterklassifizierung einzuführen,
würde das Chaos perfekt machen.

 Gerade bei den Karten gab es am Anfang des proposals für jede
 Fortbewegunsart verschiedene tags wie hikingmap und bicyclemap. Dies
 würde aber irgendwann in viele verschiedenen Kartennamen enden und
 sehr unübersichtlich werden. Du würdest damit auch die Möglichkeit der
 Orientierung an einer für den Auswerter unbekannten Karte verlieren.

Und wo ist da der Unterschied zu beliebig erweiterbaren *=yes-Tags?
Auch da muss man mit unbekannten Schlüsselwerten klarkommen.

Gruss

Sarah

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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

On Tue, Dec 22, 2009 at 12:07:37PM +0100, Andre Joost wrote:
 André Riedel schrieb:
  Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de:
 
 
  Das mit dem bicycle=yes werde ich mal als
  JOSM-Bug eintracen.
  
  Im Moment geht es aber dakor mit dem Proposal, also sollten wir zu
  nächst dies ändern oder diskutieren.
  
 
 Das bicycle=yes steht aber nun mal nicht in dem proposal.

Aber es ist schon Realität:

planet= select bicycle,count(*) from planet_osm_point where 
tourism='information' and information='guidepost' group by bicycle;

  bicycle   | count 
+---
| 13698
 designated | 1
 no |19
 yes|  1511
 permissive | 3
(5 rows)

Das heisst etwa 10% der Wegweiser sind bereits entsprechend getaggt.
Leider kann ich gerade nicht die Zahlen für hiking=* liefern.
Ich frage mich nur, was ein 'permissive' Radwegweiser ist.

Gruss

Sarah

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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

André Riedel schrieb:
 Am 11. Januar 2010 21:50 schrieb Chris-Hein Lunkhusen chris66nrw at gmx.de:
  Chris-Hein Lunkhusen schrieb:
 
  Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo
  mit bicycle=no zu taggen könnte es bei den Garmin Maps
  zu Überschneidung mit der --link-pois-to-roads Option
  kommen. In der Praxis führt es hoffentlich zur Zeit noch
  zu keinen Routingproblemen, da Wegweiser vorwiegend als
  separate Nodes getaggt sind.
 
  So, nun hab ich mich mal schlau gemacht. Also der Trigger
  für die oben genannte mkgmap Option ist der access-Tag.
 
  Nach dem Proposal [1] könnte man die Aussage: Wegweiser
  enthält Informationen für Alles außer Autos mit
  access=yes, motorcar=no taggen, und das wäre
  dann ein Problem für's Routing:
 
  http://up.picr.de/3574740.png
  ;-)
 
  Chris
 
  [1] http://wiki.openstreetmap.org/wiki/Information
 
 Schönes Beispiel, könntest du mir noch den Wegweiser dazu zeigen ;-)
 
 Meiner Meinung nach dürften alle im Proposal erwähnten Elemente nicht
 Teil eines Weges sein. Würde dies so umgesetzt werden, gäbe es dein
 Problem nie. Außerdem wird mit dieser Vereinfachung eine wichtige
 Information, der genauen Lage des Wegweisers, einfach unterschlagen.
 
 Also Wegweiser, Karte usw. mit neuen Node an genauen Standort neben
 der Straße eintragen.

Es gibt da ein kleines Problem mit der Schweiz. Hier dürften sich
geschätze 90-95% der Wegweiser auf der Strasse befinden. Ich muss
gestehen, dass das meine Schuld ist. Ich hatte damals, als ich das
Proposal für die Schweizer Wanderwege geschreiben hatte, vorgeschlagen,
die Wegweiser auf den Wegen zu plazieren, weil sie eben als Knotenpunkte
im Wanderwegenetz dienen. Es erschien mir nützlicher, sie im Wanderwege-
netz korrekt zu plazieren, als in der Landschaft. Damals hat sich 
jedenfalls keiner beschwert und die Nutzung hat sich so eingebürgert.

Ich persönlich bin auch der Meinung, dass das trotz der neuen *=yes-Tags
kein Problem ist, weil a) ein Router das Haupttag immer mitauswerten sollte
und b) ein *-no-Tag am Wegweiser nicht wirklich Sinn macht.

Wie dem auch sei, die Situation mag zwar nicht ideal sein, wird sich 
wohl aber auch nicht mehr ändern, es sei denn, jemand macht sich auf 
und verifiziert die Standorte aller 2361 eingetragenen Schweizer Wegweiser.
Es macht also nicht viel Sinn, darüber zu diskutieren, Wegweiser auf
Wegen als falsch zu deklarieren und zu verbieten.

Gruss

Sarah

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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

On Tue, Jan 12, 2010 at 06:51:36PM +0100, Felix Hartmann wrote:
 On 12.01.2010 15:12, Sarah Hoffmann wrote:
 
  Ich persönlich bin auch der Meinung, dass das trotz der neuen *=yes-Tags
  kein Problem ist, weil a) ein Router das Haupttag immer mitauswerten sollte
  und b) ein *-no-Tag am Wegweiser nicht wirklich Sinn macht.
 
 Wer sagt das guidepost oder was auch immer ein Haupttag ist. Es gibt 
 keine Definition was ein Haupttag ist, solange bicycle=yes auch alleine 
 eine Bedeutung hat. In der Datenbank steht bicycle=yes ja nicht als 
 Unterpunkt von XXX=YYY drinnen, sondern als unterpunkt des Nodes.
 Autoroutingprogramme koennen unmoeglich alle Tagkombinationen auswerten, 
 weil es da Millionen von Kombinationen gibt.

 Solange es in der Datenbank keine Moeglichkeit gibt, bicycle=yes als 
 Untertag einzutragen, kann man es also auch nicht so betrachten.
 bicycle=yes als Tag besteht schon viel laenger als 
 information=guidepost. Also kann bicycle=yes schwerlich ein Untertag von 
 information=guidepost sein.

Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten
benutzt wird, während ein Untertag nur in Kombination mit anderen Tags
anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl
etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist.
highway=* ist ein Haupttag. tourism=* eines. information=guidepost 
ist keines und bicycle=* sicherlich auch nicht.

Eben weil das Tagging-Schema bei OSM so in Fluss ist, sollte eine Software
nur Elemente auswerten, wo sie die Haupttags kennt. Alles andere wird
früher oder später zu Schwierigkeiten führen.

Gruss

Sarah

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

Re: [Talk-de] guidepost

[Sarah Hoffmann]

On Tue, Jan 12, 2010 at 10:41:55PM +0100, Norbert Hoffmann wrote:
 Sarah Hoffmann wrote:
 
 Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten
 benutzt wird, während ein Untertag nur in Kombination mit anderen Tags
 anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl
 etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist.
 highway=* ist ein Haupttag. tourism=* eines. information=guidepost 
 ist keines und bicycle=* sicherlich auch nicht.
 
 Und du schreibst also vor, das je way oder node nur genau einer dieser
 Haupttags genutzt werden darf? Ich nehme an, du überarbeitest jetzt auch
 alle Knoten, an denen derzeit z.B. amenity *und* shop vorhanden sind.

Das mit der deutschen Sprache ist schon schwer. Es geht mir nicht darum,
Regeln vorzuschreiben, sondern zu *interpretieren*, was sich in der
Datenbank befindet.

Also nochmal:
Ein Haupttag sei ein Tag, was allein an einem Weg oder Knoten vorkommen
kann, wobei kann hier so zu vestehen ist, dass es in der Datenbank
häufiger allein anzutreffen ist. Es muss nicht alleine stehen, es kann mit
beliebigen anderen Tags (auch Haupttags) vorkommen, aber es wird eben auch
alleine benutzt. Ein Untertag hingegen wird man praktisch nur in Kombination
mit anderen Tags in der Datenbank finden.

Ein Tag, dass gewöhnlich nur mit anderen Tags vorkommt, sollte ein
Datenverarbeiter besser nicht interpretieren, ohne die anderen Tags zu
betrachten. Beispiel: ein Router ignoriert gewöhnlich alle Wege, die
mit waterway=* getaggt sind, selbst wenn sie ein Tag bicycle=*
enthalten. (Ja, diese Kombination gibt es in der Datenbank.) Würde er
bedingungslos alle Wege mit bicycle=* ins Routing aufnehmen, würden
einige Leute sehr nass werden.

Am Ende liegt es natürlich am Datenverarbeiter, was genau er als Haupttag
verwenden will und wo er den Kontext (also die anderen Tags am gleichen
Knoten/Weg/Relation) interpretiert.

Gruss

Sarah

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