Re: [OSM-talk] Mapping huge lakes as coastline
On Wednesday 13 April 2011 20:24:36 M∡rtin Koppenhoefer wrote: I wonder if it would not be better to map really big lakes as coastline. This is done somewhere, e.g. here http://www.openstreetmap.org/browse/relation/555716 (Baikal lake) but it is not done here: http://www.openstreetmap.org/browse/relation/1308279 (Lake Onega) This results in bad rendering for low zoom tiles, with the lake showing up on zoom6 but not on zoom5 (in Mapnik). A few similar cases (quite big lakes modeled as water and not as coastline) can be found all over the world, e.g. - http://www.openstreetmap.org/browse/relation/1239458 (Vänern in Sweden, which by the way has a warning attached that suggests it once was a coastline ;-) ) - http://www.openstreetmap.org/browse/relation/38997 (Lago de Nicaragua) - some lakes in Canada, ... Modelling these as multipolygons also might slower the rendering speed the more complex the polygons get by adding further detail. cheers, Martin I converted a few of the biggest lakes in Finland a few years ago to coastlines, and they worked fine, until last year some other user converted them to multipolygons with natural=water -tags. He also splitted the biggest lake (Päijänne) in pieces, which created arbitrary lines across the lakes at random where the lake was divided to different polygons. The biggest lakes in Finland have tens of thousands (or even hundreds of thousands) nodes and a LOT of islands, so it's not practical to represent them as (multi)polygons IMO. Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What do you wish you'd known?
On Sat, 20 Mar 2010 00:45:56 +0200, SteveC st...@asklater.com wrote: What are the thing or things you know know that you wish you'd known when you started with OpenStreetMap? I wish I had known that the Yahoo aerial images are not rectified, as I blindly went and corrected all the roads in my neighborhood by moving them to coincide with the aerial images. In reality they already were in the correct position as they were drawn from more accurate gps-traces. Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What do you wish you'd known?
On Sat, 20 Mar 2010 11:50:13 +0200, John Smith deltafoxtrot...@gmail.com wrote: On 20 March 2010 19:42, Teemu Koskinen teemu.koski...@mbnet.fi wrote: I wish I had known that the Yahoo aerial images are not rectified, as I blindly went and corrected all the roads in my neighborhood by moving them to coincide with the aerial images. In reality they already were in the correct position as they were drawn from more accurate gps-traces. Someone mentioned this a while back, in terms of editors storing corrected image positions centrally. That only helps if the images are just offset by some amount, it doesn't help at all if they are warped, rotated etc. See eg. the centre of Helsinki: http://elanor.mine.nu/daeron/wavy.jpg All the red lines are completely straight in reality. The whole Helsinki area is full of similar errors in the Yahoo aerial images. Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping everything as areas
On Sun, 29 Nov 2009 19:03:46 +0200, John Smith deltafoxtrot...@gmail.com wrote: A thought occurred to me, that people are only planning to use areas because editors don't easily allow for widths to be entered graphically. I wonder how much work it would be if you could draw the way and then stretch it sideways to fill out the extact area you wanted covered and then the editor simply attaches the width of the way as a tag etc. With areas you can explicitly map how neighboring ways are connected to each other, this is useful for sidewalks, lanes etc. If we were to map the ways with only simple way with a width, a relation would be needed to tell that you can hop from one way to the other, which is pretty cumbersome. Also the width of a way can sometimes be so variable, that you would have to split it in hundreds of pieces, which makes handling it very hard. Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping everything as areas
On Thu, 26 Nov 2009 02:40:53 +0200, Roy Wallace waldo000...@gmail.com wrote: On Thu, Nov 26, 2009 at 8:09 AM, Anthony o...@inbox.org wrote: Now, how are you going to indicate a direction of travel on an area? I guess you could come up with some way to do it, but you'd basically be defining a way. Good point. Anyone got ideas on this? Maybe it is indeed necessary to map each highway as a way (to indicate a logical path of travel) as well as an area (to reflect reality!). A while ago I had an idea of lane type for osm, which is a directed area. I think a picture will explain it better: http://elanor.mine.nu/daeron/types.png (also includes an area type). The lane type would consist of an ordered list of node pairs. Optionally the first and last pair could contain a null node, to allow mapping a lane that branches off from another. Also maybe other pairs could contain nulls, to avoid unnecessary nodes. That way the area would have a direction, and it would be unnecessary to use ways to indicate the direction in addition to the area. This of course would need pretty major reworking of the database, editors and renderers... Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GSoC End: signFinder
On Wed, 19 Aug 2009 14:26:29 +0300, Erik Johansson e...@kth.se wrote: Since this version can't be trained to handle white background signs, I wonder what color are streetname signs around the world? Netherlands white on blue Sweden black on white In Finland: Black on white ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Revert a changeset
Could somebody please revert this changeset: http://www.openstreetmap.org/browse/changeset/2168210 The moving of the nodes across the Atlantic is obviously wrong. Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Spam] Revert a changeset
On Tue, 18 Aug 2009 20:48:03 +0300, andrzej zaborowski balr...@gmail.com wrote: 2009/8/18 Peter Miller peter.mil...@itoworld.com: On 18 Aug 2009, at 14:57, Teemu Koskinen wrote: Could somebody please revert this changeset: http://www.openstreetmap.org/browse/changeset/2168210 The moving of the nodes across the Atlantic is obviously wrong. Do check out this page for guidance and the email address for requests to the data working group. http://wiki.openstreetmap.org/wiki/Vandalism I don't think this case was deliberate vandalism, other edits from the user seems to be good. Note that I have been working on this page today and have added a section for 'speedy response' in cases where a failure to respond within hours could lead to highly visible damage to the rendered maps or changes in sensitive areas (for example Washington - particularly sensitive given the support and visibility given to OSM by the Whitehouse). Note that most incorrect edits spanning more than a few nodes need a speedy response because soon people start making edits on top of the unwanted changeset and reverting it becomes more difficult. What we need, as has been previously discussed on the list, is a similar mechanism that wikipedia has that will revert an edit easily, maybe even from the website ui. Since I had the setup for this ready, I reverted the changeset 2168210 in my changeset http://www.openstreetmap.org/browse/changeset/2192016 but I had to make a couple of edits before uploading it: * xybot had helpfully made an edit on top of some of the nodes removing a spurious tag and causing conflicts. * I did not revert the creation of node 469327157 (a parking) which seems genuine. * Something really strange: node http://www.openstreetmap.org/browse/node/270798013/history is edited two times inside the same changesets and revert.pl didn't deal correctly with this. There still seems to be some problem, the way http://www.openstreetmap.org/browse/way/39175980 still goes across the Atlantic, but it looks different than before. Personally I think we need a huge effort to be ready for damaging vandalism and much better tools to spot potential errors in a much more sophisticated way. Agreed. I spotted this with the Geofabriks OSM Inspector, but that's still a bit too slow to update, it would be much better if it updated at least hourly or even from the minute diffs. The revert tools should also be made to look what exactly was modified in the changeset. Eg. if a node was moved, but tags were left untouched, and after that someone else modified only the tags but didn't move the node, reverting the first change should only move the node back to it's original position and not change the tags back as those were changed by someone else. Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions
On Tue, 26 May 2009 08:44:54 +0300, Maarten Deen md...@xs4all.nl wrote: I've searched the wiki and I have used the tag myself, but there seems to be no documentation for restriction= ? How do you tag a restriction on a crossing between a major and a minor road where the major road is only allowed to go straight on and the minor road has no restrictions? Or in general: where the two roads do not have the same restriction. Split the major road at the crossing, then add two relations. Both relations will have the two parts of the major road and the node at the crossing. Both will have restriction=only_straigh_on, and the major road's parts will have roles to and from. The first relation would look like this: type=restriction restriction=only_straight_on from : major road part 1 via : node at the crossing to : major road part 2 And the other would be: type=restriction restriction=only_straight_on from : major road part 2 via : node at the crossing to : major road part 1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Re vert a changeset
On Tue, 26 May 2009 12:55:25 +0300, Richard Fairhurst
rich...@systemed.net wrote:
Teemu Koskinen wrote:
Could somebody revert the node changes in changeset 1315063,
someone accidentally moved big part of Hämeentie (a major street
in Helsinki). There are over a hundred moved nodes, and they are in
middle of hundreds of unmoved nodes, so it would be hard to try to
move them back by hand.
You can revert a way to an earlier version yourself, using Potlatch's
history ('H') function. This will take care of all the constituent nodes.
I know, but Hämeentie is splitted to tens of ways because of speedlimit
and lane changes, bus routes, turn restrictions etc. and there are tons of
other features nearby, so it would have taken ages to fix, even if using
potlatch's undo ;-)
But the problem seems to be corrected, user woodpeck reverted the
nodechanges.
Teemu Koskinen
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] zones for motorway/in town/outof town?
On Thu, 21 May 2009 03:13:06 +0300, Radomir Cernoch radomir.cern...@gmail.com wrote: Lennard píše v Čt 21. 05. 2009 v 01:51 +0200: Radomir Cernoch wrote: No, 'maxspeed' tag on a road does not imply a polygon with zone! There can be both in one place. Tag 'maxspeed' on a road is dominant and overrides any zonal restriction. And what if the crossing way in the above example is part of another zone? Don't say it can never happen. City planners are loopy. Ok, if you don't allow me to say that this will never happen, can you give me an example, where it could happen? I am really afraid we are solving a purely theoretical problem. We are seeking a situation, where two large areas with road networks overlap each other on a map. All streets in one area must have a different speed limit from streets in the second area. In such a situation, using maxspeed=* tag on any street must be inappropriate. http://openstreetmap.org/?lat=60.18933lon=24.9642zoom=18layers=B000FTF Sturenkatu is in 40 km/h zone, the zone continues over the bridge. Teollisuuskatu is in 50 km/h zone that is signed with the city sign. Both zones also include large amount of other roads. IIRC the 50 km/h zone can be followed from that point many kilometers, and the 40 km/h zone extends tens of roads. There also might be other overlaps between them, or with other zones. Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Fri, 24 Apr 2009 12:01:20 +0300, Ed Loach e...@loach.me.uk wrote: What is your problem with having way sections between each intersection instead of one long way? I don't have a problem with splitting ways, as that is what I've always done to add the relevant tags to the relevant section. But I can understand that there is a bit of an issue with doing such a thing. By so doing it isn't possible, currently, as far as I know, to work out at any given junction which road has priority (if any). If we didn't have to split ways, then a way could run as far as it has priority. Ways crossing it that had to give way (yield for our American readers) could end at the way to indicate they have lower priority at that junction. At a 4 way stop (American again), you could have 4 ways ending at the same node. That wouldn't work, as the name or the type of the way that has priority at the junction could change. In those cases the way must be split. There's also other possibilities when the way must be split and it would be then impossible to tell which of the ways has priority (or even cases when it would seem that a way has priority while it doesn't really have). But we do have to split ways for many reasons and I don't know how routing engines work out when one way at a junction has priority over another (or whether they even bother - I guess the best available at present is to compare names and/or refs). I did read something about road relations somewhere. I felt at the time that these, used carefully, could be used to indicate priorities at junction - so if a road crossed a road which had priority the lower priority would need a relation for either side for example. But this is complex and road relations I feel currently are probably unnecessary in most cases (I wouldn't want to create one for each residential road, though having said that I (Karlsruhe) tagged my first house numbers the other day and did an associatedStreet thing, so perhaps such relations will come with time). I'd use relations, but we would need a good scheme for it. Maybe it could be done with a relation that groups the pieces of the road, and additionally the junction nodes where you must give way (and maybe other properties too). The name, ref and all the other constant properties would be then part of the relation. That way the renderers could be happy as they could just use the relation to draw the name, ref etc. of the road while the data was split because of some other property changes, while still have the ability to fine grain control for the routers. Ed Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. About the splitting, it's already necessary to split the way if some other property changes, eg. speed limit or number of lanes (which does change more often in some places than there are restrictions), it's either the renderer's job to figure out that the pieces belong together or we could use some relation to group the pieces together but that too would require support from the renderers. Best Steve Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via-node using the way. Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
