Re: [OSM-dev] Josm bug: deleted nodes cause conflicts
On Sun, Sep 27, 2009 at 7:21 AM, malenki o...@malenki.ch wrote: But what I maybe did not express well enough was: how can the MUA decide if the CC-to/Send-to duplicate should be removed or the duplicate from ML? Sometimes there are even triplikates (can one call that so?) sent... One of the popular options these days for people who don't like duplicates, is to tick the kill duplicates option in the mailing list configuration. That way each user can decide for themselves whether they want duplicates or not. (The way it works is that the mailing list server checks the To and CC fields and if your address is in there it doesn't send you another copy). http://www.list.org/mailman-member/node21.html Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Josm bug: deleted nodes cause conflicts
2009/9/29 Martijn van Oosterhout klep...@gmail.com: One of the popular options these days for people who don't like duplicates, is to tick the kill duplicates option in the mailing list configuration. That way each user can decide for themselves whether they want duplicates or not. It's a pity we can't just tick a box and have the reply-to changed on a per user basis, that would solve most if not all the arguments on this silly topic. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Josm bug: deleted nodes cause conflicts
Martijn van Oosterhout klep...@gmail.com writes: On Sun, Sep 27, 2009 at 7:21 AM, malenki o...@malenki.ch wrote: But what I maybe did not express well enough was: how can the MUA decide if the CC-to/Send-to duplicate should be removed or the duplicate from ML? Sometimes there are even triplikates (can one call that so?) sent... One of the popular options these days for people who don't like duplicates, is to tick the kill duplicates option in the mailing list configuration. That way each user can decide for themselves whether they want duplicates or not. (The way it works is that the mailing list server checks the To and CC fields and if your address is in there it doesn't send you another copy). Unfortunately, this is not practicable if you want to have the list headers (List-Id for example) in list mails. It is the same problem as with duplicate suppression on the receiving side because the direct mail usually arrives first. I am interested in a way to have Cyrus' duplicate suppression only kick in when the duplicate is delivered to the same inbox folder (after sieve filtering). Of course, this is even more OT here than the rest of this thread. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Empty tags created by Potlatch
Hi list, somehow a user managed to create empty tags on a node: http://www.openstreetmap.org/browse/node/513414350/history Is this a bug or a feature? Regards, Marc signature.asc Description: This is a digitally signed message part. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Empty tags created by Potlatch
Marc Schütz wrote: somehow a user managed to create empty tags on a node: http://www.openstreetmap.org/browse/node/513414350/history Is this a bug or a feature? I don't know, but if you can provide steps to reproduce I can look at it. cheers Richard -- View this message in context: http://www.nabble.com/Empty-tags-created-by-Potlatch-tp25663965p25665031.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Empty tags created by Potlatch
On Tue, 29 Sep 2009 08:15:24 -0700 (PDT), Richard Fairhurst rich...@systemed.net wrote: Marc Schütz wrote: somehow a user managed to create empty tags on a node: http://www.openstreetmap.org/browse/node/513414350/history Is this a bug or a feature? I don't know, but if you can provide steps to reproduce I can look at it. First: can it be confirmed that the tag was actually empty? Potlatch does accept tags filled with only a space, and if you look at the history of a node on the weg, it looks as there is no character there. Maarten ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Black Roads
Hey guys. I appear to have a problem with the M4 motorway in London. Almost all of the road is correctly styled, however one part is completely black. I've attached an example. Does anyone know why this has happened and how to resolve it? http://maps.m4.net/osm_tiles2/14/8178/5449.png -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Empty tags created by Potlatch
Am Dienstag 29 September 2009 17:31:26 schrieb Maarten Deen: On Tue, 29 Sep 2009 08:15:24 -0700 (PDT), Richard Fairhurst rich...@systemed.net wrote: Marc Schütz wrote: somehow a user managed to create empty tags on a node: http://www.openstreetmap.org/browse/node/513414350/history Is this a bug or a feature? I don't know, but if you can provide steps to reproduce I can look at it. Sorry, I haven't asked him yet. First: can it be confirmed that the tag was actually empty? Potlatch does accept tags filled with only a space, and if you look at the history of a node on the weg, it looks as there is no character there. Here is an excerpt from the hexdump of the XML linked from the history page: 0110 3d 22 70 6c 61 63 65 22 20 76 3d 22 22 2f 3e 0a |=place v=/.| As you can see, there is nothing between the two (22 22). Regards, Marc signature.asc Description: This is a digitally signed message part. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
I appear to have a problem with the M4 motorway in London. Almost all of the road is correctly styled, however one part is completely black. I've attached an example. Does anyone know why this has happened and how to resolve it? http://maps.m4.net/osm_tiles2/14/8178/5449.png The permalink would be (but actually it's not working somehow?) http://maps.m4.net/?zoom=14lon=-0.3076171875lat=51.49506473014368 And for the OSM Main-Map (where everything is fine) http://www.openstreetmap.org/?zoom=14lon=-0.3076171875lat=51.49506473014368 When you take a very close look on the area where the M4 is connected to the Great West Road (A4), you'll see that not all of them are black. The Data-Layer on osm.org tell you, that the black parts are those that are tagged with bridge: yes and layer: 2 (eg. http://www.openstreetmap.org/browse/way/38815535) It seems there are some bad rules in the mapnik styles for highway=motorway_link / highway=motorway with bridge=yes. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] shp2osm.pl
Tobias (I am also CCing this to the OSM dev mailing list), I am using your shp2osm.pl script to convert a shapefile from my property appraiser's office. In the output, I'm getting nodes and ways that look like this: node id='-1' visible='true' lat='28.1728386606802' lon='-82.5595546812076' / node id='-2' visible='true' lat='28.1719197697234' lon='-82.559526525786' / node id='-3' visible='true' lat='28.1719160567277' lon='-82.5591091374846' / node id='-4' visible='true' lat='28.1710175353132' lon='-82.5590593295055' / node id='-5' visible='true' lat='28.1710180004217' lon='-82.5591044662532' / node id='-6' visible='true' lat='28.1710220551224' lon='-82.559499009353' / node id='-7' visible='true' lat='28.1710226815735' lon='-82.5595610568869' / node id='-8' visible='true' lat='28.1728390673479' lon='-82.5596167297582' / node id='-9' visible='true' lat='28.1728386606802' lon='-82.5595546812076' / way id='-10' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-3' / nd ref='-4' / nd ref='-5' / nd ref='-6' / nd ref='-7' / nd ref='-8' / nd ref='-9' / nd ref='-9' / tag k=BLDG v=0.0/ tag k=ACREAGE v=1.34/ [...] /way As you can see, nodes -1 and -9 are identical. Fine, I can write a separate perl script to combine them. But node -9 is being listed twice in the way. I looked at the code and found the culprit: push @segs, seg_out $last_node, $first_node if $first_node $connect_last_seg; But I can't figure out quite why that's there or what it's meant to do. My understanding is that the proper way for OSM purposes should be: node id='-1' visible='true' lat='28.1728386606802' lon='-82.5595546812076' / node id='-2' visible='true' lat='28.1719197697234' lon='-82.559526525786' / node id='-3' visible='true' lat='28.1719160567277' lon='-82.5591091374846' / node id='-4' visible='true' lat='28.1710175353132' lon='-82.5590593295055' / node id='-5' visible='true' lat='28.1710180004217' lon='-82.5591044662532' / node id='-6' visible='true' lat='28.1710220551224' lon='-82.559499009353' / node id='-7' visible='true' lat='28.1710226815735' lon='-82.5595610568869' / node id='-8' visible='true' lat='28.1728390673479' lon='-82.5596167297582' / way id='-9' visible='true' nd ref='-1' / nd ref='-2' / nd ref='-3' / nd ref='-4' / nd ref='-5' / nd ref='-6' / nd ref='-7' / nd ref='-8' / nd ref='-1' / tag k=BLDG v=0.0/ tag k=ACREAGE v=1.34/ [...] /way But I thought I'd check with you and the dev list to see if I'm perhaps missing something. Thanks, Anthony DiPierro ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Peter Körner wrote: It seems there are some bad rules in the mapnik styles for highway=motorway_link / highway=motorway with bridge=yes. Ah, the missing info in the original mail was that he rendered it himself. I went looking at osm.org for those black roads, but couldn't find them and assumed it was a fluke, and already fixed. Richard, before you go on a quest to find those bad rules in the mapnik styles, could you update your render toolchain* to the latest versions and then try again? * osm2pgsql, default.style, osm.xml, mapnik I predict that when you take a look in the postgresql logs, you'll see queries that have failed because of missing columns, or whatnot. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Thanks for you help. I assume, as I have to re-install osm2pgsql, I will have to re-import the planet.osm? Regards, Richard Ive Lennard wrote: Peter Körner wrote: It seems there are some bad rules in the mapnik styles for highway=motorway_link / highway=motorway with bridge=yes. Ah, the missing info in the original mail was that he rendered it himself. I went looking at osm.org for those black roads, but couldn't find them and assumed it was a fluke, and already fixed. Richard, before you go on a quest to find those bad rules in the mapnik styles, could you update your render toolchain* to the latest versions and then try again? * osm2pgsql, default.style, osm.xml, mapnik I predict that when you take a look in the postgresql logs, you'll see queries that have failed because of missing columns, or whatnot. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Black Roads
Richard Ive wrote: Thanks for you help. I assume, as I have to re-install osm2pgsql, I will have to re-import the planet.osm? Only if your black roads are actually caused by missing columns in your db. Check your postgresql logs. If it is caused by your mapnik being too old, and unable to handle the multiline SQL currently in osm.xml, you don't have to reimport the planet, but just update mapnik to release 0.6.1 or newer (svn). Newer mapnik versions are also more vocal about problems in the stylesheet, so I would recommend building from svn. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
Sorry if this is a duplicate, sending using my other email address which is the one subscribed to the list... On Tue, Sep 29, 2009 at 6:00 PM, Peter Körner osm-li...@mazdermind.dewrote: Please, if you can, fix it! If you can, commit directly or post a patch otherwise! this is a major bug that *needs* to be fixed *fast*! This needs to be reviewed. I'm not really a perl guru, and some reference magic is being done which I don't really understand. Plus I'm new to OSM. But I've attached a quick patch. In the longer term, I'd like to merge nodes throughout the entire file when they are duplicated in more than one polygon. And I believe it has been suggested to use boundary relations rather than polygons in cases where there are a lot of overlapping boundaries. But if someone with some knowledge of perl and OSM looks this patch over, it should be enough to fix the bug in the short term. Anthony shp2osm.patch Description: Binary data ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
And I believe it has been suggested to use boundary relations rather than polygons in cases where there are a lot of overlapping boundaries. Yes, I'ts not good to have overlapping ways - they are a mess to edit and they can be constructed by relations, as well. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
On Tue, Sep 29, 2009 at 6:09 PM, Peter Körner osm-li...@mazdermind.dewrote: And I believe it has been suggested to use boundary relations rather than polygons in cases where there are a lot of overlapping boundaries. Yes, I'ts not good to have overlapping ways - they are a mess to edit and they can be constructed by relations, as well. I've been hoping someone would strike up a conversation with me on a good algorithm to find and relation-ize overlapping boundary ways. I would love to implement this... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
On Tue, Sep 29, 2009 at 7:35 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Sep 29, 2009 at 6:09 PM, Peter Körner osm-li...@mazdermind.dewrote: And I believe it has been suggested to use boundary relations rather than polygons in cases where there are a lot of overlapping boundaries. Yes, I'ts not good to have overlapping ways - they are a mess to edit and they can be constructed by relations, as well. I've been hoping someone would strike up a conversation with me on a good algorithm to find and relation-ize overlapping boundary ways. I would love to implement this... Can we assume the shared ways use shared nodes? I was planning on making that assumption, because I believe it's true for the particular data I'm trying to import. Without that assumption, it's probably too much work for the time I have. In any case, I have to worry about converting the multipolygons from the shapefile I have first. I'm pretty sure there are some, in the standard holes go clockwise format, and shp2osm doesn't handle that as far as I can tell. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
On Tue, Sep 29, 2009 at 6:58 PM, Anthony o...@inbox.org wrote: On Tue, Sep 29, 2009 at 7:35 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Sep 29, 2009 at 6:09 PM, Peter Körner osm-li...@mazdermind.dewrote: And I believe it has been suggested to use boundary relations rather than polygons in cases where there are a lot of overlapping boundaries. Yes, I'ts not good to have overlapping ways - they are a mess to edit and they can be constructed by relations, as well. I've been hoping someone would strike up a conversation with me on a good algorithm to find and relation-ize overlapping boundary ways. I would love to implement this... Can we assume the shared ways use shared nodes? I was planning on making that assumption, because I believe it's true for the particular data I'm trying to import. Without that assumption, it's probably too much work for the time I have. No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations. e.g.: Two neighboring square country borders: one with nodes a,b,c,d and one with nodes w,x,y,z: a--bw--x | | | c--dy--z Nodes b and w are exactly overlapping, but are part of two different ways. In any case, I have to worry about converting the multipolygons from the shapefile I have first. I'm pretty sure there are some, in the standard holes go clockwise format, and shp2osm doesn't handle that as far as I can tell. My Java version of shp-to-osm handled this automatically. It appears to me that the shapefile format follows the same model we do: clockwise for outer rings and anti-clockwise for inner rings (e.g. holes). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
On Tue, Sep 29, 2009 at 8:34 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Sep 29, 2009 at 6:58 PM, Anthony o...@inbox.org wrote: Can we assume the shared ways use shared nodes? I was planning on making that assumption, because I believe it's true for the particular data I'm trying to import. Without that assumption, it's probably too much work for the time I have. No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations. Okay, I was imprecise (a terrible thing when dealing with this topic, so my apologies). Before I dealt with those other problems I was going to be to go through my data and merge any nodes with shared locations into shared nodes. I'll probably do this while importing the data into a database, and it should be very easy. I need the database because I want to be able to extract sections of the data (individual neighborhoods at a time), and I've currently got a half gig shapefile (which converts to a 1.7 gig .osm file), which seems to have the polygons in fairly random order. I'm a little worried there might be situations like this, though: w--x | | a--b | | | | c--d | | | y--z With WY overlapping BD, but not sharing any nodes. If you think you can attack that situation, I'd be happy to help. In any case, I have to worry about converting the multipolygons from the shapefile I have first. I'm pretty sure there are some, in the standard holes go clockwise format, and shp2osm doesn't handle that as far as I can tell. My Java version of shp-to-osm handled this automatically. It appears to me that the shapefile format follows the same model we do: clockwise for outer rings and anti-clockwise for inner rings (e.g. holes). I should probably check out the java version. Does this use the old 0.4 method, or the new multipolygon relations? I guess using multipolygon relations won't be too bad. I just leave the tags off all but one outer way (whatever one has the biggest area?), and then reference them in a relation (calculating the area to determine clockwise/anti-clockwise). Ugh, it sounds so easy until you get down to the nitty gritty. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shp2osm.pl
On Tue, Sep 29, 2009 at 8:01 PM, Anthony o...@inbox.org wrote: On Tue, Sep 29, 2009 at 8:34 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Sep 29, 2009 at 6:58 PM, Anthony o...@inbox.org wrote: Can we assume the shared ways use shared nodes? I was planning on making that assumption, because I believe it's true for the particular data I'm trying to import. Without that assumption, it's probably too much work for the time I have. No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations. Okay, I was imprecise (a terrible thing when dealing with this topic, so my apologies). Before I dealt with those other problems I was going to be to go through my data and merge any nodes with shared locations into shared nodes. I'll probably do this while importing the data into a database, and it should be very easy. I need the database because I want to be able to extract sections of the data (individual neighborhoods at a time), and I've currently got a half gig shapefile (which converts to a 1.7 gig .osm file), which seems to have the polygons in fairly random order. I'm a little worried there might be situations like this, though: w--x | | a--b | | | | c--d | | | y--z With WY overlapping BD, but not sharing any nodes. If you think you can attack that situation, I'd be happy to help. In this case, I don't consider way WY to be overlapping with BD. I would only consider them overlapping if nodes B and D are part of the way WXYZ. In any case, I have to worry about converting the multipolygons from the shapefile I have first. I'm pretty sure there are some, in the standard holes go clockwise format, and shp2osm doesn't handle that as far as I can tell. My Java version of shp-to-osm handled this automatically. It appears to me that the shapefile format follows the same model we do: clockwise for outer rings and anti-clockwise for inner rings (e.g. holes). I should probably check out the java version. Does this use the old 0.4 method, or the new multipolygon relations? I rewrote it a while ago to use multipolygon relations when ways are 2000 nodes and when the shapefile contains a multipolygon. http://redmine.yellowbkpk.com/projects/show/geo I guess using multipolygon relations won't be too bad. I just leave the tags off all but one outer way (whatever one has the biggest area?), and then reference them in a relation (calculating the area to determine clockwise/anti-clockwise). I currently put the tags on the multipolygon relation, but yes, the polygon's tags should end up on the outer ways according to the wiki page. Ugh, it sounds so easy until you get down to the nitty gritty. Yep :) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Statistics on changesets by created_by=*
On Wed, Sep 30, 2009 at 1:14 AM, Ævar Arnfjörð Bjarmason ava...@gmail.comwrote: TomH provided me with statistics on created_by=* in all changeset tags[1][2][3]. Here are with more than 1000 total changesets ordered by the number of changesets: 813222 = JOSM, 730972 = Potlatch, 96066 = Merkaartor, 40213 = bulk_upload.py, 34625 = upload.py, 17443 = KMLManager, 7995 = FreieTonne, 4620 = osmtools, 3779 = OTHERS, 1271 = mat's little ruby script, 898= osm2go, So JOSM is über alles it would appear. Caveat: Only when considering the number of changesets. If one would like to consider the number of primitives (nodes, ways, relations) edited then the results will likely be different (I'm guessing the bulk imports would go up a level or two). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
