Re: [josm-dev] Wireframe saves the day for a complex multipolygon
On Sun, Feb 07, 2010 at 09:33:59PM +0200, Teemu Koskinen wrote: I fixed them, but i disagree on the correctness of natural=land. The multipolygon relation already unambiguously says that the holes are land if there's no other tags sayng that it's eg. wood etc. Thanks for stepping forward and explaining this. Your change note did not specify what was done or why it was done. Given that Northern Finland is very sparsely populated and there are very few roads in the Inarinjärvi area, I would make an educated guess that most of the islands are uninhabited, in more or less natural state. In more populated areas, I would hesitate to make educated guesses for landuse, and I could leave the island polygons untagged until more is known about them. Also if the lake-within-island doesn't itself have islands, it doesn't need to be a multipolygon, as it is residing in the hole (island) of the larger lake. As long as the island is given some tags that identify it as an area, I believe that multipolygons have to be defined for the island-with-lakes. I defined multipolygons for the few Inarinjärvi islands with lakes. For what it is worth, I replaced the natural=land tags to the islands last night, before reading your message. Feel free to remove them again; I do not want to get into an edit war. Best regards, Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Changes recorded by JOSM when changing a key
Hi, someone discovered and asked why in my changeset http://www.openstreetmap.org/api/0.6/changeset/3818805/download I had tagged various bridges as bridge with value different. I had chosen a spelling-error via OSMdoc (maybe it was brigde or something the like), corrected the key and uploaded the changed values. But for some reason JOSM didn't just change the key (I think it did at some point in the past?) but actually wrote the different-value that was in the edit-dialog. a) What would be the easiest way to find out which (other) changes I might have messed up yesterday (looking for date:yesterday, submitter:neufeind and different somewhere in the values) and how to revert those changes? b) Does somebody know if that's known problem? Is there a fix/workaround? Kind regards, Stefan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changes recorded by JOSM when changing a key
On Mon, 8 Feb 2010, Stefan Neufeind wrote: someone discovered and asked why in my changeset http://www.openstreetmap.org/api/0.6/changeset/3818805/download I had tagged various bridges as bridge with value different. I had chosen a spelling-error via OSMdoc (maybe it was brigde or something the like), corrected the key and uploaded the changed values. But for some reason JOSM didn't just change the key (I think it did at some point in the past?) but actually wrote the different-value that was in the edit-dialog. a) What would be the easiest way to find out which (other) changes I might have messed up yesterday (looking for date:yesterday, submitter:neufeind and different somewhere in the values) and how to revert those changes? Ask Frederik Ramm. He usually helps to revert such bad errors. He will probably also be able to find other changesets with same error. b) Does somebody know if that's known problem? Is there a fix/workaround? Now it is a fixed problem. In case you tried to change the properties, but actually you did not change the key there was an error that the value was taken as is (i.e. not properly reconstructed). Indeed a very bad error. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Wireframe saves the day for a complex multipolygon
Marko Mäkelä marko.mak...@iki.fi writes: As long as the island is given some tags that identify it as an area, I believe that multipolygons have to be defined for the island-with-lakes. Why? You don't consider the lake on the island as part of the island? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Wireframe saves the day for a complex multipolygon
On Mon, Feb 08, 2010 at 07:13:08AM -0500, Matthias Julius wrote: Marko Mäkelä marko.mak...@iki.fi writes: As long as the island is given some tags that identify it as an area, I believe that multipolygons have to be defined for the island-with-lakes. Why? You don't consider the lake on the island as part of the island? Not any more than I would consider the island on the lake as part of the lake. For instance, should an island polygon be tagged landuse=residential, the lake on the island would not be part of the residential area. Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changes recorded by JOSM when changing a key
Hi, Dirk Stöcker wrote: a) What would be the easiest way to find out which (other) changes I might have messed up yesterday (looking for date:yesterday, submitter:neufeind and different somewhere in the values) and how to revert those changes? Ask Frederik Ramm. He usually helps to revert such bad errors. He will probably also be able to find other changesets with same error. I don't know if I should feel pleased to be recommended as the first port of call for OSM wreckage of any kind ;-) here's a few tips how such a situation could be investigated. If you know the date, then you can download the daily change file, in this case http://planet.openstreetmap.org/daily/20100207-20100208.osc.gz and either work on that with plain old grep, or use the slightly more comfortable oscgrep.pl (from /svn.openstreetmap.org/applications/utils/filter/oscgrep) which lets you do this: perl oscgrep.pl -a modify -r 'user=neufeind.*different' 20100207-20100208.osc.gz to find all objects which user neufeind modified and tagged with something that included different. In this case we find that you have tagged 2201 objects with bridge=different (and no other ...=different). Strangely, 2152 of them are nodes, and only 49 are ways. All this happened in changeset 3818805. I started the process of reverting those changes, but of course this will revert objects to their old and also broken state. (Many of the 2152 nodes probably shouldn't have the bridge tag at all - perhaps, rather than a wholesale replacement, these should be checked individually.) But you are not alone, there are 364 bicycle=different, 174 building=different, 241 highway=different, 343 lanes=different, 1138 waterway=different and a lot of other things as well. I particularly like the 19 occurrences of source=different;extrapolation from DOP which show that automatic concatenation of tag values with a semicolon is perhaps not ideal. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changes recorded by JOSM when changing a key
On Mon, 8 Feb 2010, Frederik Ramm wrote: a) What would be the easiest way to find out which (other) changes I might have messed up yesterday (looking for date:yesterday, submitter:neufeind and different somewhere in the values) and how to revert those changes? Ask Frederik Ramm. He usually helps to revert such bad errors. He will probably also be able to find other changesets with same error. I don't know if I should feel pleased to be recommended as the first port of call for OSM wreckage of any kind ;-) here's a few tips how such a situation could be investigated. We are working on josm to be THE tool to help fixing such issues. Until then you are still the number one :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] trac: please provide a link to go back to last page after login
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi. Is it possible to provide a link to the last page visited, abter login, or maybe stay at tha page. Right now I am always send to the main wiki-page after login. Thanks Colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAktwGgUACgkQalWTFLzqsCtqHQCgxCjfTfTMQdLbl8rTEO0Pac3c 5l8AnRZtLmWquQ53LyO7Vefn+RdQua2O =JzaF -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] trac: please provide a link to go back to last page after login
2010/2/8 colliar colliar4e...@aol.com: Hi. Is it possible to provide a link to the last page visited, abter login, or maybe stay at tha page. Right now I am always send to the main wiki-page after login. a simple workaround: hit browser-back-button. Reload. - Still I think you're right: the current behaviour is a littlel annoying. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] trac: please provide a link to go back to last page after login
On Mon, 8 Feb 2010, Martin Koppenhoefer wrote: Is it possible to provide a link to the last page visited, abter login, or maybe stay at tha page. Right now I am always send to the main wiki-page after login. a simple workaround: hit browser-back-button. Reload. - Still I think you're right: the current behaviour is a littlel annoying. Sorry but I do not understand your problem. For me the website stays on the same page as before when doing a login. Search parameters and dynamic content will be stripped thought. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] trac: please provide a link to go back to last page after login
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I am using iceweasel (Debian-3.5.6-1, on a up-to_date debian squeeze. May I try a different browser. Thanks for the work around (I forgot to press reload). cu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAktwLDYACgkQalWTFLzqsCtuYQCg5cRBwPGYwNMx4a6OGSVHgPPy lgwAn00jiS5OD11ohkmPzMFynSEPjktS =rtUo -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] trac: please provide a link to go back to last page after login
Dirk Stöcker wrote: Sorry but I do not understand your problem. For me the website stays on the same page as before when doing a login. Maybe, but for us mortals it does not perform this magic. Instead, my workflow is as follows: click a link to a ticket; click login; enter credentials; the main site is loaded; accept invalid certificate; click browser 'go back' button; change http:// to https://; reload. __ Basti ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] trac: please provide a link to go back to last page after login
On Mon, 8 Feb 2010, Sebastian Klein wrote: Maybe, but for us mortals it does not perform this magic. Instead, my workflow is as follows: click a link to a ticket; click login; enter credentials; This does my browser automatically. :-) the main site is loaded; ... accept invalid certificate; This also. It is self-signed, not invalid! click browser 'go back' button; change http:// to https://; reload. Well, when you change http to https before you login, then it works. Seems protocol crossing links aren't preserved. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Introduce versioning scheme
Hi, I was wondering, why we still have revision numbers for the releases. I assume, most users won't know the concept of software revisions (and don't care) but are much more familiar with handy version numbers. The fact that the version of the plugins is one magnitude higher than the JOSM number, has caused some confusion, as well. It would be a little more work for the maintainer, but I think it's feasible. :) For the last 10 tested versions it could look like this, for example: 0.10.1-r1566 0.11.1-r1607 0.12.1-r1669 0.13.1-r1788 0.14.1-r1981 0.15.1-r2221 0.15.2-r2255 0.16.1-r2552 0.16.2-r2554 0.16.3-r2561 (Start with some arbitrary positive number as minor version and increment the minor version for each new tested. Bug fix follow ups could get a third level number. A Zero as major version would indicate the beta state and that bugs are to be expected. Finally append the revision number.) I am open for other suggestions, though. JOSM has a lot of unconventional behavior (e.g. editing modes, right mouse click panning, the whole Java handling, webkit installation, etc.). The revision numbers alone are not a big deal, but the small hurdles add up and at each stage, a certain fraction of users gives up. It would be nice, if we could also reach more people with only little technical skills. __ Basti P.S.: Interesting, there has been a release in each month. r1566 | 2009-04-30 15:59:56 +0200 (Thu, 30 Apr 2009) r1607 | 2009-05-20 16:08:00 +0200 (Wed, 20 May 2009) r1669 | 2009-06-14 17:34:52 +0200 (Sun, 14 Jun 2009) r1788 | 2009-07-14 18:20:56 +0200 (Tue, 14 Jul 2009) r1981 | 2009-08-18 15:21:37 +0200 (Tue, 18 Aug 2009) r2221 | 2009-09-30 21:04:36 +0200 (Wed, 30 Sep 2009) r2255 | 2009-10-07 21:25:15 +0200 (Wed, 07 Oct 2009) r2552 | 2009-11-30 00:02:22 +0100 (Mon, 30 Nov 2009) r2554 | 2009-11-30 13:48:36 +0100 (Mon, 30 Nov 2009) r2561 | 2009-12-01 21:37:23 +0100 (Tue, 01 Dec 2009) - no, wait - December doesn't count and January is just over.. :) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
Hi Sebastian Absolutely. That's one of the things we should do in the next release: * proper release naming * proper labeling in SVN I came up with a slightly different naming scheme, though. If we want to be understood by users with less technical background a release name 0.10.1-r1566 could be quite cryptic. Why not simply call it 2010.01 (first release in 2010), 2010.02, etc. ? There won't be more than 4 releases a year anyway. I don't really see the need for a version number with three levels of increments. See for instance Ubuntu release numbering: https://help.ubuntu.com/6.10/ubuntu/about-ubuntu/C/version-numbers.html Regards Karl Am 08.02.2010 21:49, schrieb Sebastian Klein: Hi, I was wondering, why we still have revision numbers for the releases. I assume, most users won't know the concept of software revisions (and don't care) but are much more familiar with handy version numbers. The fact that the version of the plugins is one magnitude higher than the JOSM number, has caused some confusion, as well. It would be a little more work for the maintainer, but I think it's feasible. :) For the last 10 tested versions it could look like this, for example: 0.10.1-r1566 0.11.1-r1607 0.12.1-r1669 0.13.1-r1788 0.14.1-r1981 0.15.1-r2221 0.15.2-r2255 0.16.1-r2552 0.16.2-r2554 0.16.3-r2561 (Start with some arbitrary positive number as minor version and increment the minor version for each new tested. Bug fix follow ups could get a third level number. A Zero as major version would indicate the beta state and that bugs are to be expected. Finally append the revision number.) I am open for other suggestions, though. JOSM has a lot of unconventional behavior (e.g. editing modes, right mouse click panning, the whole Java handling, webkit installation, etc.). The revision numbers alone are not a big deal, but the small hurdles add up and at each stage, a certain fraction of users gives up. It would be nice, if we could also reach more people with only little technical skills. __ Basti P.S.: Interesting, there has been a release in each month. r1566 | 2009-04-30 15:59:56 +0200 (Thu, 30 Apr 2009) r1607 | 2009-05-20 16:08:00 +0200 (Wed, 20 May 2009) r1669 | 2009-06-14 17:34:52 +0200 (Sun, 14 Jun 2009) r1788 | 2009-07-14 18:20:56 +0200 (Tue, 14 Jul 2009) r1981 | 2009-08-18 15:21:37 +0200 (Tue, 18 Aug 2009) r2221 | 2009-09-30 21:04:36 +0200 (Wed, 30 Sep 2009) r2255 | 2009-10-07 21:25:15 +0200 (Wed, 07 Oct 2009) r2552 | 2009-11-30 00:02:22 +0100 (Mon, 30 Nov 2009) r2554 | 2009-11-30 13:48:36 +0100 (Mon, 30 Nov 2009) r2561 | 2009-12-01 21:37:23 +0100 (Tue, 01 Dec 2009) - no, wait - December doesn't count and January is just over.. :) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
Karl Guggisberg wrote: Hi Sebastian Absolutely. That's one of the things we should do in the next release: * proper release naming * proper labeling in SVN I came up with a slightly different naming scheme, though. If we want to be understood by users with less technical background a release name 0.10.1-r1566 could be quite cryptic. Yes, it looks a little cryptic like that, but you can write it shorter: JOSM 0.16 or more verbose: JOSM 0.16 (3rd revision, build 2561) Why not simply call it 2010.01 (first release in 2010), 2010.02, etc. ? There won't be more than 4 releases a year anyway. I don't really see the need for a version number with three levels of increments. See for instance Ubuntu release numbering: https://help.ubuntu.com/6.10/ubuntu/about-ubuntu/C/version-numbers.html Your scheme is simple and solid. We should avoid however, that 2010.02 gets misinterpreted as the February release of 2010. (Maybe write it as 2010.2 or 2010-v2) Note that Ubuntu has scheduled releases, they use the year and the month to denote the version. But that shouldn't stop us to use the year and an incremented number. The bug fixing releases still need to be named somehow. It should be easily recognizable on the main page, that an update of the current release is available. __ Basti ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
2010/2/8 Sebastian Klein basti...@googlemail.com: Yes, it looks a little cryptic like that, but you can write it shorter: JOSM 0.16 or more verbose: JOSM 0.16 (3rd revision, build 2561) What about JOSM 1.16? Is JOSM still pre 1.0 ? cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
Karl Guggisberg karl.guggisb...@guggis.ch writes: Hi Sebastian Absolutely. That's one of the things we should do in the next release: * proper release naming * proper labeling in SVN I came up with a slightly different naming scheme, though. If we want to be understood by users with less technical background a release name 0.10.1-r1566 could be quite cryptic. I don't think the revision number needs to be part of the version number. Otherwise what is the point of sticking another number in front of it? We are not planning to make a release with every commit. The revision could be displayed in the About dialog. Also, I think a major and a minor version is enough. If it should really become necessary to fix a tested version we can stick a patch version number on it. For development I think it is best to stick with revision numbers. Why not simply call it 2010.01 (first release in 2010), 2010.02, etc. ? There won't be more than 4 releases a year anyway. I don't really see the need for a version number with three levels of increments. See for instance Ubuntu release numbering: https://help.ubuntu.com/6.10/ubuntu/about-ubuntu/C/version-numbers.html Personally, I don't like those year based version numbers. IMHO they only make sense if you follow a strictly yearly schedule. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
At 2010-02-08 20:28, Matthias Julius wrote: Personally, I don't like those year based version numbers. IMHO they only make sense if you follow a strictly yearly schedule. They do, however, eliminate the inevitable debate of what constitutes a major vs. minor release. -- Alan Mintz alan_mintz+...@earthlink.net ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
