AW: I18n of JOSM plugins (with Gradle build) via Transifex
> I hope this proves useful It does! I'll merge your related pull request for the scripting plugin shortly. -- Karl -Ursprüngliche Nachricht- Von: Florian Schäfer [mailto:flor...@schaeferban.de] Gesendet: Dienstag, 16. Januar 2018 12:19 An: josm-dev@openstreetmap.org Betreff: I18n of JOSM plugins (with Gradle build) via Transifex Hello fellow JOSM developers, I'd like to make an announcement for plugin developers and translators: TL;DR: Translators, you can now translate a few JOSM plugins at Transifex.com [1] (the other translations are still on Launchpad). Plugin developers, if you are building with Gradle you can now easily export and import strings for i18n using Gradle. ### Very recently I added i18n support to the gradle-josm-plugin [2]. Starting with v0.3.1, JOSM plugins using Gradle as build system can export translatable strings and later process the translated strings. Since in the past there were occasional thoughts to switch to Transifex for translations [3][4], I figured this would be a good opportunity to try to migrate a few plugins over. Maybe it proves useful for future efforts in this direction. So I started to upload translatable strings to Transifex yesterday. At the moment the translatable strings for the JOSM plugins `Mapillary` and `geojson` are now available on Transifex. Both plugins can now be translated on both platforms, but I'd like to migrate the `Mapillary` plugin to Transifex completely to avoid that translation work is done two times on two different platforms. I'll leave it up to the other maintainers of JOSM plugins built with Gradle to decide if and where to translate the plugins [5]. Quick statistics: AFAIK there are eight plugins built with Gradle, seven of these use the gradle-josm-plugin, of those all except `Mapillary` and `geojson` are currently not translated at all. Is there a simple way to disable pushing translations to Launchpad for the Mapillary plugin? Or would it be easier to remove the plugin from the Ant build? I think, the Gradle build offers all necessary functionality now, so it wouldn't hurt much to only build with Gradle. For me, i18n was the last big bit that was missing in the Gradle build. I hope this proves useful for some developers/translators. If you have any feedback, questions or other comments, feel free to write it here. With kind regards, Florian aka floscher P.S.: I'd like to emphasize, that I don't want to force anything onto other developers, neither Gradle nor Transifex. These are the choices I made for the Mapillary plugin and which I'm offering in the form of the gradle-josm-plugin to everybody who's interested. --- [1]: https://transifex.com/josm/josm [2]: https://github.com/floscher/gradle-josm-plugin , instructions for i18n at https://github.com/floscher/gradle-josm-plugin/blob/master/docs /I18n.md#readme [3]: https://josm.openstreetmap.de/ticket/8645 [4]: https://lists.openstreetmap.org/pipermail/josm-dev/2017-February/0 07791.html [5]: I didn't ask the maintainer(s) of the geojson plugin yet. If they want to stay with Launchpad, I'll remove the project from Transifex again. For the moment it only serves demonstration purposes.
Re: [josm-dev] JOSM donations?
I read you opinion, I accept it, I don't necessarily agree with it, but I won't discuss it on the list. 2011/8/1 Dirk Stöcker openstreet...@dstoecker.de On Mon, 1 Aug 2011, Paul Hartmann wrote: after this is mainly flaming against me and no longer private I may answer. And own server - you know what I think about JOSM being more and more a client to some JOSM server somewhere. I'd like to get rid of the server instead of building up even more capacity which will doubtless be filled by you with lots of clever Python contraptions that nobody else can maintain. Exactly, for god's sake, don't put stoeckr in a position where he can hack up even more Perl spagetti, which is closed source for security reasons. I still don't know what your problem is Karl. You have been a valuably contributor in the past but as soon as not everything went the way you wanted it, you went mad. It is an accident this text got to the mailing list, but actually I find it rather strange, that you send flames to Paul, but never had the courage to contact me. Instead of collect money then see how we spend it, I'd suggest define what we want, find out what it costs, then ask people to donate to OSM/FOSSGIS for that specific cause. - If a cause can be found that is worth spending money on, and I'm not convinced yet. Exactly, there is clearly potential for payed work from which both a potential sponsor and the community benefits, without the community to be compromised. It is possible, we've all done this in the past, but I very much doubt that it would be possible again, if stoeckr was involved Well, what do you refer to? I only know one time when we had something like this in the past and this is turnrestrictions plugin. And actually this is an example which shows the opposite: The author got money for it, but he no longer cares about. The plugin was abandoned shortly after it has been created. Nobody does necessary bug fixes ATM. So this is an argument for Frederik, who says that bounties wont work. Ciao -- http://www.dstoecker.eu/ (PGP key available) __**_ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/josm-devhttp://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] question about UI strings in plugins
I think it has changed, right?
Yes. The rules are much simpler now:
* Always escape single quotes with '', regardless of whether you use tr(),
trn(), or trc().
#4160 http://josm.openstreetmap.de/ticket/4160 still claims that double
quotes won't work in the french translation but the ticket has
never been confirmed and it is probably outdated.
Regards
Karl
Am 18.04.2010 13:47, schrieb Sebastian Klein:
Frederik Ramm wrote:
Simply add whatever you want in a tr() call. That serves as a hook for
the i18n engine but of it remains untranslated then it will just display
as-is. Make sure to use proper number formatting and the singular/plural
stuff (trn()).
There is some kind of script that runs over all the source files and
collects the strings for translation. (in the folder editors/josm/i18n)
The strings are uploaded to launchpad and all the translations are then
copied to core/data/*.lang. This is done manually approximately once a week.
From the wiki page
http://josm.openstreetmap.de/wiki/DevelopersGuide/StyleGuide :
wrong: new JLabel(tr(My Label + labelId));
right: new JLabel(tr(My Label {0}, labelId));
Can anyone confirm that the following still holds:
For simple strings without substitution you need not change anything:
new JButton(tr(Don't press me!))
For tr with more than one parameter, the apostrophe is special. (Like
backslash in C)
It needs to be escaped by another apostrophe:
new JButton(tr(Don''t press me more than {0} times!, n))
I think it has changed, right?
__
Sebastian
___
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] Function to select or download a sequence of ways?
Hi Marko To the best of my knowlege there is no such function yet ... As a further development, it could be useful to create a selective download function (follow this way until reaching a branch or a given bounding box). ... except for this function which sounds like what the waydownloader plugin provides. Selection is a core thing. You can use it from plugins in three ways. (1) you can influence the current selection. See setSelected() on DataSet. Invoke it on the current data layer (Main.main.getEditLayer()) (2) you can get the current selection. See getSelected() on DataSet. Invoke it on the current data layer (Main.main.getEditLayer()) (3) you can listen to the current selection. See org.openstreetmap.josm.data.osm.event.SelectionEventManager Regards Karl Am 09.03.2010 10:07, schrieb Marko Mäkelä: Before I start reinventing the wheel in JOSM, I would like to know if there is a function or plugin that allows to select a non-branching sequence of ways. It would be nice if the selection function could optionally be restricted to the current selection, just like the search dialog, and if some predicates could be assigned to the ways, say, highway=tertiary or natural=coastline, so that any branches where the predicate does not hold would be ignored. With such a selection function, it would be easy to select the coastline of an area within a natural=coastline extract of the planet extract, or to select a section of highway or railway for defining a route relation, for instance. Last, some questions to help getting me started, in case this does not exist yet. Is the selection a core thing, or can this be done in a plugin? Where should I start looking first? As a further development, it could be useful to create a selective download function (follow this way until reaching a branch or a given bounding box). Best regards, Marko ___ 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] how does the transition to tested work ?
Hi Colliar Yes, you're right, that's how how most professionals in most other commercial and OS projects work, or at least try to work. Unfortunately, JOSM is different. The JOSM release process is one of the many JOSMisms which are often hard to understand for both JOSM users and JOSM contributors. Please forget about the r-2010-01-blockers. They've been introduced in an attempt to prepare and stabilize a release when the current maintainer handed over responsibility to two of us, because he didn't have time. Just ignore them. The current maintainer is apparently back in business. Actually, two of us is wrong. bastik took over responsibility and did most of the work for the last tested build, thanks! Regards Karl Am 08.03.2010 12:33, schrieb colliar: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Thanks a lot for your work. I still wonder how the transition to tested works. As bug #4666 is/was really annoying but is fixed now exists still in r3070. This has also effects on update data (see #4663). Please update tested to r3081. I also find 5 bugs left with keyword: r-2010-01-blocker. Are you planning to solve them before working on upstream ? I think tested should be a version without any blocker/critical bug reported on and being tested as unstable/latest for a week. cu co -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuU4HQACgkQalWTFLzqsCvMywCgs8SAs189fgYDMY+gekkB0dB9 TaQAn2mUVrBjnhUcp65UukpXrA2YvCCz =5hlO -END PGP SIGNATURE- ___ 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] how does the transition to tested work ?
maybe we should add a comment that uploads should be done in 1 transaction only until this bug is fixed. This wouldn't really help. Even if data is uploaded in one transaction (i.e. with exactly one upload into one changeset before the changeset is closed), we may run into the problem if the user cancels the upload. Anyway, a warning message couldn't harm, but I'd display it when the user cancels an upload. It should read something along the lines of: * if the upload included new objects You canceled the upload of new objects. If you retry the upload the same objects could be uploaded again. Before the next upload please update your data and run validator for duplicate nodes. * if the upload didn't included new objects You canceled an upload. If you retry the upload you might create a lot of conflicts because your local dataset might be out of sync with the data on the server. Before the next upload please update your data and resolve any conflicts. But both these warnings aren't really helpful because in both cases you may end up with strange data and/or a lot of work (resolving hundreds of conflicts, for instance). We will probably have to implement the workaround described in #4401 and hope for an improved API/protocol in API 0.7. -- Karl Am 08.03.2010 17:15, schrieb Apollinaris Schoell: On 8 Mar 2010, at 7:04 , Sebastian Klein wrote: #4401 (JOSM does not remember what has been uploaded) It's more like an enhancement. Too complicated, will be fixed after release. for me this is really a bug not an enhancement. Josm is used for semi automatic imports a lot and this creates big mess of duplicates on server/network interrupts. I know it wasn't designed for that but Josm is just such a great workhorse. on normal editing this can leave a user with conflicts after a partial upload, maybe we should add a comment that uploads should be done in 1 transaction only until this bug is fixed. Anyway thanks for the great work and it's better to have a stable again. Josm is improving big with every release:) ___ 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 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] how does the transition to tested work ?
Yes, conflict resolution today is clearly not well-designed for mass resolution of conflicts. Openening a dialog, resolving the conflict, and closing the dialog again, is very tedious if you have to resolve more than, say, 20 conflicts. This is a major issue which I think should be adressed soon. It won't replace the current feature for resolving an individual conflict, but it should complete it with better support for mass resolution. Regards Karl Am 08.03.2010 17:39, schrieb Ævar Arnfjörð Bjarmason: On Mon, Mar 8, 2010 at 16:30, Dirk Stöckeropenstreet...@dstoecker.de wrote: On Mon, 8 Mar 2010, Ævar Arnfjörð Bjarmason wrote: for me this is really a bug not an enhancement. Josm is used for semi automatic imports a lot and this creates big mess of duplicates on server/network interrupts. I know it wasn't designed for that but Josm is just such a great workhorse. on normal editing this can leave a user with conflicts after a partial upload, maybe we should add a comment that uploads should be done in 1 transaction only until this bug is fixed. Anyway thanks for the great work and it's better to have a stable again. Josm is improving big with every release:) The problem with recommending that is that the only reason for using one object at a time uploading is to narrow down conflicts you may be having, right now due to this bug at the cost of adding lots of duplicates to the database. To have better conflict solving you may use Update modified from first menu. This will produce all conflicts in one single run and allows them to fix in one go. Yes, but due to the bad interface for conflict resolution in JOSM this isn't an option sometimes. There isn't support for mass-resolution of similar conflicts (I've filed bugs for this) so you run into situations where you can either: * Solve 300 conflicts which are of the same nature manually. Which requires for each one: 1. Click on an item in the conflict list 2. Move to tags/whatever in the dialog 3. Click merge your/remote changes 4. Apply 5 Repeat After I'm done with that I'll have manually clicked UI elements at least 300*4 times or so. So instead of doing that when I run into it I just cut my losses and try to upload at least /some/ of my data. I do this by turning on single-object upload, trying to select subsets of the dataset and see if I can upload them without conflicts. ___ 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] svn:eol-style=native
Hi, that's fine for me. I've now updated my local SVN config too. Regards Karl Am 04.03.2010 11:16, schrieb Sebastian Klein: Hi, I'd like to set svn:eol-style=native for 481 source files. Any objections? One-third (207) of the files already have this flag. Btw, you can put the following in the subversion config: enable-auto-props = yes *.java = svn:eol-style=native This way all added files get the property by default. __ Sebastian ___ 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
[josm-dev] Next release end of February: status update
Hi, work on the next JOSM release scheduled for end of February is progressing well, see http://josm.openstreetmap.de/wiki/DevelopersGuide/Release-2010-01. Currently, there are five defects flagged as release blocker (i.e. they should be fixed before the next release because they affect basic and often used features or because they might lead to lost or corrupt data), down from 20 release blocker in total. Work on translations is going well too. Sebastian is frequently synchronizing launchpad and the JOSM source tree. Currently, there are 20 messages not translated yet in German. Are there other languages targeting 100% translation converage for the next release too? We had some discussions on this list whether the announced switch to Java 1.6 is reasonable or not. My impression is, that there is consensus in the JOSM community that the migration makes sense, even though there are a few users who won't be happy with a new, Java 1.6 based JOSM (mainly users of Mac OSs withouth support for Java 1.6). Based on a thread on this list I've written down a proposal for a future Build and Release Number scheme, see http://josm.openstreetmap.de/wiki/DevelopersGuide/ReleaseNumbers. I've tried to summarize the discussion in the thread but the final proposal is obviously biased toward what I like most. Please post to this list if you have any objections or leave a note on the wiki. If this proposal was to be followed the next release would be named *JOSM 10.1*. Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] deleting relations fails due to not fullfiled prerequirements
Hi Werner I'd say it's a JOSM *feature*, not a defect. JOSM correctly detects that the server wasn't able to delete a relation because it was still in use by some other relation. Simple workaround: Remove 73724 first and 73723 with a second changeset. That's how to do it. It isn't a workaround. Regards Karl Am 13.02.2010 10:04, schrieb Werner Hoch: Hi there, I'm not sure if this is a JOSM problem. I've tried to delete the relations 73723 and 73724. 73723 is the only element of 73724. http://www.openstreetmap.org/browse/relation/73724 When I try to upload the change, I get an error message that 73723 cannot be deleted because it is an element of 73724. The complete message is (German): - Vorbedingung nicht erfüllt Die Relation 73723 konnte nicht gelöscht werden. Sie wird immer noch von Relation 73724 referenziert. Bitte laden Sie die Relation 73724, entfernen Sie die Referenz auf Relation 73723 und laden Sie erneut hoch. -- I think that the prerequirements are fullfiled if relation 73724 is removed, too. Simple workaround: Remove 73724 first and 73723 with a second changeset. I'm using JOSM version 2561. Regards Werner ___ 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
ehem, sorry for the posting in german ... Regard Karl Am 09.02.2010 19:21, schrieb Dirk Stöcker: On Tue, 9 Feb 2010, Karl Guggisberg wrote: Also all released JOSM jar files are signed, so you can use Java to verify signature. Handelt es sich dabei um einen Teil des bisher nicht veröffentlichen Build-Scripts für Releases? In ant.xml kann ich auf den ersten Blick keine entsprechende Funktion erkennen. Kannst du das bisher verwendete Build-Script publizieren? Wie siehts mit Zertifikaten aus? All releases are signed. Each nightly build. As said latest and tested are only softlinks to these. So for release the only thing to do is say This build is release. I don't like to make the build scripts open as it runs automatically and with too much knowledge about the scripts hacking the server probably becomes much easier (everything has flaws and you must not make them too obvious :-) And there is no real necessarity beside Nice to know. Ciao ___ 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
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] Please don't delete http://josm.openstreetmap.de/wiki/HaitiLessonsLearned
Hi, you're free to create trac tickets as you wish and you already did. This page is by no means a replacement of trac ticketing system and I ask you again not to delete it. If these are personal notes, then why use an common wiki page instead of a personal file on your harddisk? Because I did so. I don't have to justify. Regards Karl Am 28.01.2010 09:27, schrieb Dirk Stöcker: On Wed, 27 Jan 2010, Karl Guggisberg wrote: For some reasons I don't understand stoecker got upset because the page exists and threatens to delete it. I want to keep it. It's no big deal, I'm not upset. But there have been numerous cases like this in the past and people always refer to these pages when they are long-time outdated (and they get outdated very fast). Thus my comment to make the issues trac tickets instead of a project-related issue collection. These issues have nothing to do with Haiti at all, so the project-relating is useless. these are my personal notes, don't read it if you don't like it, just ignore it if you don't like the concept of a wiki and/or the content. I don't mind. If these are personal notes, then why use an common wiki page instead of a personal file on your harddisk? Ciao ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please don't delete http://josm.openstreetmap.de/wiki/HaitiLessonsLearned
Hi, I will not delete the page now (which I never considered), but it will not stay there longer than approx. 2 months. I'll continue to work actively with this page and I let you know when it is not needed anymore or I'll delete it myself, if I feel necessary (remember, for whatever reason I was granted wiki admin rights too). Until then feel free to contribute in any reasonable way in the tradition of working with wikis. Creating tickets and adding the ticket ids was a welcome added value. Thanks Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Please don't delete http://josm.openstreetmap.de/wiki/HaitiLessonsLearned
Hi, I'm currently contributing to the mapping activities in Haiti. As a sideeffect I learn a lot about JOSM, how it used by other and how it could better support relief efforts in crisis situations. I take some notes at http://josm.openstreetmap.de/wiki/HaitiLessonsLearned. For some reasons I don't understand stoecker got upset because the page exists and threatens to delete it. I want to keep it. It's no big deal, these are my personal notes, don't read it if you don't like it, just ignore it if you don't like the concept of a wiki and/or the content. I don't mind. This is just to announce, that I'll continue to work with this page in the near future and I ask everybody not to delete this page. Thanks. Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Remove tooltips in relation list dialog
Hi Sebastian not from my side, go ahead. Regards Karl Am 19.01.2010 21:50, schrieb Sebastian Klein: Hi, I'd like to remove the tooltips from relation list dialog and layer list dialog. It isn't unique information, but can be quite distracting (See #3639 and #4227 for example). Any objections? __ Basti ___ 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] Plugin for wifi geolocalization inside building ...
Hi, please read this: http://josm.openstreetmap.de/wiki/DevelopersGuide/CreateBuild Regards Karl Am 14.01.2010 10:41, schrieb Minh Quang: Hi everyone, I would like to know how to add a number version to application JOSM. In fact, when I compile JOSM, I have just an executable file without the number version. It will make me difficult to download other plugins like PicLayer which will demands JOSM version 2.561 +. Thanks everyone --- On Wed, 1/13/10, Sebastian Kleinbasti...@googlemail.com wrote: From: Sebastian Kleinbasti...@googlemail.com Subject: Re: [josm-dev] Plugin for wifi geolocalization inside building ... To: josm-dev@openstreetmap.org Date: Wednesday, January 13, 2010, 12:35 PM Minh Quang wrote: Hi, Thanks for your reply. As you sugested, we can use the filter to hide and display objects according to their tags. Now, I dont know how to use this feature, I send you PM on how to activate this feature. in which directory, I can find it... Thanks I'm sure you find out yourself. :) ___ 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 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugin for wifi geolocalization inside building ...
Hi, I'll give you a few pointers to further information. I you want to create a plugin which creates layers, downloads and uploads geo-data, manipulates data in the background, etc. you can't avoid to get familiar with a subset of the JOSM code base. Read it and write one or more small prototypes to get hands-on experience. Nobody on this list can relieve you from this burden. If you run into trouble ask again. * Read the code in org.openstreetmap.josm.gui.layer. In particular, have a look at OsmDataLayer. Find out, how an OsmDataLayer is currently created in JOSM and try to mimic this in your plugin. * Read the code in org.openstreetmap.josm.data.osm, in particular OsmPrimitive.java, Node.java, Way.java and Relation.java. You'll have to manipulate them. Another cornerstone is DataSet.java. That's where your inhouse objects will be kept in JOSM (or your plugin). Each OsmDataLayer has a DataSet. * Have a look at the classes in org.openstreetmap.josm.io. OsmServerReader reads geo-data as XML from an input stream and replies a DataSet. Want to see it in action? Then have a look at org.openstreetmap.josm.actions.downloadtasks.DownloadOsmTask. This is also an example on how JOSM currently runs asynchronous tasks. Are you aware of this page: http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins ? You should read it too. It gives you additional infos about creating a JOSM plugin. Regards Karl Am 14.01.2010 15:38, schrieb Minh Quang: youpi, Thanks for your help. Now, I would like to work on the JOSM's objects with our personalized tags. What I want to do is to create the same number of layers as floors there are inside a building, and to position objects inside each layer according to their floor tags. =), another question is how JOSM control their objects. There is a translation from data dowloaded to JOSM's objects... Thanks in advance --- On *Thu, 1/14/10, Karl Guggisberg /karl.guggisb...@guggis.ch/* wrote: From: Karl Guggisberg karl.guggisb...@guggis.ch Subject: Re: [josm-dev] Plugin for wifi geolocalization inside building ... To: josm-dev@openstreetmap.org Date: Thursday, January 14, 2010, 10:50 AM Hi, please read this: http://josm.openstreetmap.de/wiki/DevelopersGuide/CreateBuild Regards Karl Am 14.01.2010 10:41, schrieb Minh Quang: Hi everyone, I would like to know how to add a number version to application JOSM. In fact, when I compile JOSM, I have just an executable file without the number version. It will make me difficult to download other plugins like PicLayer which will demands JOSM version 2.561 +. Thanks everyone --- On Wed, 1/13/10, Sebastian Kleinbasti...@googlemail.com /mc/compose?to=basti...@googlemail.com wrote: From: Sebastian Kleinbasti...@googlemail.com /mc/compose?to=basti...@googlemail.com Subject: Re: [josm-dev] Plugin for wifi geolocalization inside building ... To: josm-dev@openstreetmap.org /mc/compose?to=josm-...@openstreetmap.org Date: Wednesday, January 13, 2010, 12:35 PM Minh Quang wrote: Hi, Thanks for your reply. As you sugested, we can use the filter to hide and display objects according to their tags. Now, I dont know how to use this feature, I send you PM on how to activate this feature. in which directory, I can find it... Thanks I'm sure you find out yourself. :) ___ josm-dev mailing list josm-dev@openstreetmap.org /mc/compose?to=josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org /mc/compose?to=josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org /mc/compose?to=josm-...@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] Localisation policy for quotes etc.
Sure, but the latest commits fixing english messages are really exagerating Its download link is not known. instead of isn't known ? Hey, these are just error messages, it's not the Queen addressing the nation. --Karl Am 13.01.2010 17:48, schrieb Frederik Ramm: Hi, Marc Schütz wrote: Well Marc Schütz is in theory completely wrong that don't and do not are not freely interchangeable. Don't is a contraction of do not and means exactly the same thing by definition. Then why is not this sentence right? Can we simply agree that the apostroph'd forms are not used in formal English and move on? Ain't so hard ;-) Bye Frederik ___ 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] Localisation policy for quotes etc.
forgot to add: thanks to mjulius and others for cleaning up all these messages! It was indeed necessary and the result is a big improvent, even though I feel that the wording could be a little bit less formal in some cases. -- Karl Sure, but the latest commits fixing english messages are really exagerating Its download link is not known. instead of isn't known ? Hey, these are just error messages, it's not the Queen addressing the nation. --Karl Am 13.01.2010 17:48, schrieb Frederik Ramm: Hi, Marc Schütz wrote: Well Marc Schütz is in theory completely wrong that don't and do not are not freely interchangeable. Don't is a contraction of do not and means exactly the same thing by definition. Then why is not this sentence right? Can we simply agree that the apostroph'd forms are not used in formal English and move on? Ain't so hard ;-) Bye Frederik ___ 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] Localisation policy for quotes etc.
Hi,
It's always a single quite in English, but perhaps they're double
quotes in the JOSM source to work around something?:
tr(abc) doesn't use MessageFormat. A single quote in tr(...) therefore
isn't a meta-character and is copied to the output.
tr(a single quote ' ) - a single quote '
tr(a {0}, test) uses MessageFormat. There, single quotes are
meta-character. A single quote is the (close) equivalent to \ in regexp: it
allows to escape curly braces. '} is }, '' is '.Therefore, if you have a I18n
string with format placeholders and single quotes, you MUST escape them with
two quotes. If you don't MessageFormat won't process the format placeholders
correctly and single quotes are deleted.
tr(a single quote '' - {0} , OK) - a single quote ' - OK
tr(a single quote ' - {0} , NOK) - a single quote - NOK (or a
single quote - {0} because formatting fails)
At least that's what you have to do today unless somebody changes the tr()
implementations in I18n. If tr(...) was to use MessageFormat too, single
quotes would always have to be escaped with another single quote.
The HTML is rendered by some internal Java stuff, both of those tags
work just as well when fed to it so I don't think it needs to be fixed
either way.
AFAIK, the internal Java stuff doesn't support br/. Even worse, if you use
it instead ofbr the HTML rendering is sometimes messed up. This holds for
labels, tooltips and for JEditorPane.
Regards
Karl
Am 10.01.2010 16:13, schrieb Ævar Arnfjörð Bjarmason:
On Sun, Jan 10, 2010 at 15:00, Andre Hinrichsandre.hinri...@gmx.de wrote:
Hi List!
Since I currently check all translatable texts I found that sometimes
quotes are single and sometimes double. E.g. isn't is sometimes simply
isn't and sometimes isn''t.
Which is the correct way?
It's always a single quite in English, but perhaps they're double
quotes in the JOSM source to work around something?:
aoeu josm (r2766) $ ack tr\(.*isn''t src
src/org/openstreetmap/josm/gui/download/BoundingBoxSelection.java
219:setErrorMessage(tfLatValue,tr(The string ''{0}''
isn''t a valid double value., tfLatValue.getText()));
251:setErrorMessage(tfLonValue,tr(The string ''{0}''
isn''t a valid double value., tfLonValue.getText()));
src/org/openstreetmap/josm/gui/widgets/BoundingBoxSelectionPanel.java
160:feedbackInvalid(tr(The string ''{0}'' isn''t a
valid double value., getComponent().getText()));
200:feedbackInvalid(tr(The string ''{0}'' isn''t a
valid double value., getComponent().getText()));
src/org/openstreetmap/josm/gui/dialogs/changeset/query/AdvancedChangesetQueryPanel.java
533:throw new IllegalStateException(tr(Current
value ''{0}'' for user ID isn''t valid, tfUid.getText()));
Forthermore I find sometimes american english (e.g. 'initialize').
Wasn't the overall policy to use british english?
I thought the source default was en_US since if it was en_GB the
existing en_GB translation would be pointless (and we'd need a en_US
one).
And finally sometimes I find XHTML style end tags in translated texts
(e.g. 'br /' instead of'br'). By now I haven't found any in the
source. Is it ok to use them or should these be fixed?
The HTML is rendered by some internal Java stuff, both of those tags
work just as well when fed to it so I don't think it needs to be fixed
either way.
___
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] Localisation policy for quotes etc.
Hi Andre
Ok, understood. Only thing is, that in Launchpad I cannot see whether it
is a MessageFormat or not. So I have to trust the original text to be in
correct format, haven't I?
Yes, you can. If there is at least one format placeholder {0}, {1}, etc. in the
text you see in Launchpad, then you must escape all single quotes with another
single quote. If there isn't, you shouldn't escape them.
Regards Karl
Am 10.01.2010 16:53, schrieb Andre Hinrichs:
Am Sonntag, den 10.01.2010, 16:31 +0100 schrieb Karl Guggisberg:
Hi,
It's always a single quite in English, but perhaps they're double
quotes in the JOSM source to work around something?:
tr(abc) doesn't use MessageFormat. A single quote in tr(...) therefore
isn't a meta-character and is copied to the output.
tr(a single quote ' ) - a single quote '
tr(a {0}, test) uses MessageFormat. There, single quotes are
meta-character. A single quote is the (close) equivalent to \ in regexp: it
allows to escape curly braces. '} is }, '' is '.Therefore, if you have a
I18n string with format placeholders and single quotes, you MUST escape them
with two quotes. If you don't MessageFormat won't process the format
placeholders correctly and single quotes are deleted.
tr(a single quote '' - {0} , OK) - a single quote ' - OK
tr(a single quote ' - {0} , NOK) - a single quote - NOK (or
a single quote - {0} because formatting fails)
Ok, understood. Only thing is, that in Launchpad I cannot see whether it
is a MessageFormat or not. So I have to trust the original text to be in
correct format, haven't I?
At least that's what you have to do today unless somebody changes the tr()
implementations in I18n. If tr(...) was to use MessageFormat too, single
quotes would always have to be escaped with another single quote.
The HTML is rendered by some internal Java stuff, both of those tags
work just as well when fed to it so I don't think it needs to be fixed
either way.
AFAIK, the internal Java stuff doesn't support br/. Even worse, if you
use it instead ofbr the HTML rendering is sometimes messed up. This
holds for labels, tooltips and for JEditorPane.
I'll check that later this evening.
Am 10.01.2010 16:13, schrieb Ævar Arnfjörð Bjarmason:
On Sun, Jan 10, 2010 at 15:00, Andre Hinrichsandre.hinri...@gmx.de
wrote:
Hi List!
Since I currently check all translatable texts I found that sometimes
quotes are single and sometimes double. E.g. isn't is sometimes simply
isn't and sometimes isn''t.
Which is the correct way?
It's always a single quite in English, but perhaps they're double
quotes in the JOSM source to work around something?:
aoeu josm (r2766) $ ack tr\(.*isn''t src
src/org/openstreetmap/josm/gui/download/BoundingBoxSelection.java
219:setErrorMessage(tfLatValue,tr(The string ''{0}''
isn''t a valid double value., tfLatValue.getText()));
251:setErrorMessage(tfLonValue,tr(The string ''{0}''
isn''t a valid double value., tfLonValue.getText()));
src/org/openstreetmap/josm/gui/widgets/BoundingBoxSelectionPanel.java
160:feedbackInvalid(tr(The string ''{0}'' isn''t a
valid double value., getComponent().getText()));
200:feedbackInvalid(tr(The string ''{0}'' isn''t a
valid double value., getComponent().getText()));
src/org/openstreetmap/josm/gui/dialogs/changeset/query/AdvancedChangesetQueryPanel.java
533:throw new IllegalStateException(tr(Current
value ''{0}'' for user ID isn''t valid, tfUid.getText()));
Forthermore I find sometimes american english (e.g. 'initialize').
Wasn't the overall policy to use british english?
I thought the source default was en_US since if it was en_GB the
existing en_GB translation would be pointless (and we'd need a en_US
one).
Makes sense. The only british english policy is for the OSM tags, I
think.
And finally sometimes I find XHTML style end tags in translated texts
(e.g. 'br /' instead of'br'). By now I haven't found any in the
source. Is it ok to use them or should these be fixed?
The HTML is rendered by some internal Java stuff, both of those tags
work just as well when fed to it so I don't think it needs to be fixed
either way.
Thank you both for the quit response!
Regards
Andre
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localization of exception messages
Hi,
I would vote for removing those lokalizations.
Me too. There are lots of them, though, and I even have to admin that lots of
them have been introduced by me. In hindsight this looks increasingly silly. We
should follow more appropriate rules than those currently mentioned in
http://josm.openstreetmap.de/wiki/DevelopersGuide/StyleGuide#Internationalization
For instance
- DONT translate messages of unchecked exceptions. This includes
RuntimeException, IllegalParameterExceptions, IllegalStateException and the
like.
- DONT translate messages of assert statements and AssertExceptions
- DO translate messages of checked exceptions
Regards
Karl
Am 08.01.2010 21:06, schrieb Matthias Julius:
I noticed that some exceptions get localized messages like this one:
IllegalArgumentException(tr(Parameter ''{0}'' must not be null., tags))
Does this really help anyone? Those messages are intended to be for
developers and users probably won't know what to do even with the best
translation. On top of that most of the developers won't understand
most of the localized messages (I understand only a very small subset
of them) which is making it harder to understand bug reports.
I would vote for removing those lokalizations. I don't know how many
there are but this will also reduce the load on translators and the
size of the language files a bit.
Other opinions?
Matthias
___
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] Changeset Upload Policy/Strategy
Hi, yes, there is a difference. Strategy is used for http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/io/UploadStrategy.java Policy is used for http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/io/MaxChangesetSizeExceededPolicy.java The two concepts are orthogonal and have to be named differently. I've chosen strategy for the former because it represents three possible approaches to run uploads. The later is called a policy because it represents three possible decisions to be taken in case an upload hits the size limit for a changeset. But feel free to change the names in whatever suits you better. Don't forget to update the online help too, though. http://josm.openstreetmap.de/wiki/Help/Action/Upload Regards Karl Am 03.01.2010 13:17, schrieb Frederik Ramm: Hi, while working on translations I encountered some confusion in the source, namely it seems to me that the words changeset upload strategy and changeset upload policy are used interchangeably. I wanted to fix that but found that this would require renaming a number of methods and classes, so I refrained from it for the time being, not wanting to break anything - but could someone confirm that there is indeed no conceptual difference between the two, and ideally rename stuff (to strategy, I would suggest)? Or have I misread the situation and there is a difference? Bye Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Problems with SVN commit
Hi, could somebody with server access please have a look at http://josm.openstreetmap.de/ticket/4137 The problems with SVN commit are annoying. Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] UpdateModifiedAction ?
Hi, r2682 adds an UpdateModifiedAction. The changeset looks fine http://josm.openstreetmap.de/changeset/2682/ The file was indeed added and checked in. Stragenly, UpdateModifiedAction.java isn't checked out when I update to HEAD, in contrast to the updates in MainMenu.java referring to it. Any idea what is wrong here? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Login at josm.openstreetmap.de fails
Hi, Currently, it's not possible to login to http://josm.openstreetmap.de. Here's what trac says: Trac Error Authentication information not available. Please refer to the installation documentation https://josm.openstreetmap.de/error/HTTP_UNAUTHORIZED.html.var/wiki/TracInstall#ConfiguringAuthentication. TracGuide https://josm.openstreetmap.de/error/HTTP_UNAUTHORIZED.html.var/wiki/TracGuide --- The Trac User and Administration Guide Could somebody with server access please have a look? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Login at josm.openstreetmap.de fails
By the way: I can only use https, when I'm logged in on trac. Would it be possible get it to work with plain http? This way it is faster and I need not accept the invalid certificate all the time... :) I second that. -- Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Jave 5 and help browser issue
Probably we should consider switching to version 5. You mean version *6*, don't you? I second that and I propose to do it in the next release cycle (probably to be released around end of 01/2010?). --Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Samstag, 28. November 2009 14:20 An: josm-dev@openstreetmap.org Betreff: [josm-dev] Jave 5 and help browser issue On Sat, 28 Nov 2009, Sebastian Klein wrote: a) Security issues. When you launch an application you must be sure it is really the right one. Isn't it similarly insecure to run binary plugins that are located in the user's home folder? To a certain degree yes. b) Installation issues. Java must be installed in a way, that you can launch it. True, but shouldn't be a problem in practice. (There are java apps that are run by a script. They must have figured this out somehow.) There is already one report for this issue which means this is a real problem. c) Does not work in Webstart variant or as applet. That's a problem... How many Webstart users are there? One could simply redirect the help to a browser window for these people. (Or use modal help for webstarters only.) About 4700 webstart accesses in last 3 weeks. Whenever we switch to Java 6, we can solve that issue with different modal modes as supported by Java 6. Btw. may I ask what are the main reasons for using Java 5? (Other than support users that haven't updated their Java for 3 years.) Good question. Current stats (about 3 weeks): 5 ( 1137, 4%) 6 (23625, 95%) 7 ( 57, 0%) Java 5 is not really an issue anymore. Probably we should consider switching to version 5. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] List of key names
Hi, standard JOSM just displays the tags availabe in the current data set. There's a plugin, the tageditor plugin, http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TagEditor which displays both, a list of *standard values* (Map Features from http://wiki.openstreetmap.org/wiki/Map_Features) and a list of *current values* from the dataset. I'd be interested in a patch/update for the tageditor's tag definitions: http://svn.openstreetmap.org/applications/editors/josm/plugins/tageditor/res ources/osm-tag-definitions.xml Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Hans F. Nordhaug Gesendet: Dienstag, 17. November 2009 02:40 An: josm-dev@openstreetmap.org Betreff: [josm-dev] List of key names Hi! When adding keys to a node it's very nice to be able to select key names from the dropdown menu in stead of typing it, to avoid typos like is_in:contry ... However, many commonly used key names are missing. Is this intentionally or do you want a patch with some of the missing key names? Regards, Hans ___ 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
[josm-dev] Problem with commiting
Hi, I get the following error message when I try to commit: Permission denied svn: Commit failed (details follow): svn: Can't open file '/var/svn/josm/db/txn-current-lock': Permission denied Anybody having the same problem? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] JOSM download with tile numbers?
Hi, one of the tabs in JOSMs download can be used to specify a download area with tile numbers. Is there anybody actually using this? Who would actually know tile numbers? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Selection handling
Hi Dave, I saw that your patch regarding selection handling was commited: http://josm.openstreetmap.de/ticket/3676 When you introduce a new selection cache in the future, could you make sure it's *ordered*, i.e. it reflects the order in which primitives are selected (could be a list, an ordered set, instead of a plain collection)? This would be an important prerequisite for a couple of trac tickets asking for * adding the current selection as relation members *in order* * picking the *firts* selected node as target node in node merging * picking the *firts* selected way as target way in way combining Thanks and regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Remove internal help browser?
Regarding this F1 thing - no one will get it. Best you can do is put some big inviting help button on the dialog that might need explanation. I already started to do that. See the new help aware option pane http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/He lpAwareOptionPane.java and two examples I've migrated http://josm.openstreetmap.de/wiki/Help/Concepts/Conflict I plan to do the same thing in the message dialog for error messages created by the server, see http://josm.openstreetmap.de/ticket/2882 Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Sebastian Klein Gesendet: Freitag, 9. Oktober 2009 21:45 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Remove internal help browser? Karl Guggisberg wrote: Hi, I plan to remove JOSMs internal help browser and to always delegate to an external browser, for two reasons: Good idea. Having an internal browser for help seems quite strange and old-fashioned to me. Also, the current version is far from usable. Nowadays, if there is some problem, you open a browser and google it. If it isn't answered in some forum immediately, you will at least find the documentation and try to resolve it there. Regarding this F1 thing - no one will get it. Best you can do is put some big inviting help button on the dialog that might need explanation. (But only if there is some documentation available.) It's quite pointless to press F1 and get an empty page each time. Dirk Stöcker wrote: Yes. External browsers have too many drawbacks regarding visibility and launching. If you do not like the internal one, then make it configurable to disable it. So many applications do this browser launch thing, it can't be that awful. Cheers, Sebastian ___ 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] Selection Performance
I was referring to the discusion about backreferences and referreres http://lists.openstreetmap.org/pipermail/josm-dev/2009-October/003435.html -- Karl -Ursprüngliche Nachricht- Von: Dave Hansen [mailto:d...@sr71.net] Gesendet: Donnerstag, 8. Oktober 2009 18:45 An: karl.guggisb...@guggis.ch Cc: 'Petr Nejedlý'; 'josm-dev' Betreff: Re: AW: [josm-dev] Selection Performance On Thu, 2009-10-08 at 18:35 +0200, Karl Guggisberg wrote: 1. to migrate to node.setSelected(..) and way.isSelected() 2. to change the behaviour behind OsmPrimitive:setSelected()/isSelected(), possibly using a reference from the primitive to it's parent dataset (see recent dicussion about backreference in this list) I think I missed this discussion. Do you have any pointers to it? A quick nabble search also didn't turn anything up. -- Dave ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Selection Performance
So I would go even further and deprecate/remove the selection notion from the primitive altogether. It is used in few places only anyway (beyond painting) and would be well served by a selection set on the Layer anyway. I support that. -- Karl -Ursprüngliche Nachricht- Von: Petr Nejedlý [mailto:p...@nejedli.cz] Gesendet: Donnerstag, 8. Oktober 2009 22:55 An: karl.guggisb...@guggis.ch Cc: 'Dave Hansen'; 'josm-dev' Betreff: Re: AW: [josm-dev] Selection Performance Dave Hansen napsal(a): On Thu, 2009-10-08 at 10:18 +0200, Petr Nejedlý wrote: First and foremost, selection status is not a property of the data. Changing the data set just because the user have selected something is plain wrong. Having a per-dataset selection is quite disturbing too - there should be only one, system-wide. OK, so you're saying that because selecting things is not a property of the data that it shouldn't be a part of the data set? Uh, ok. Aren't ways and nodes part of the data set? Check out OsmPrimitive.setSelected(). Sure seems to *ME* like selections are part of the data set. Selections are currently part of the OSMPrimitive API, sure. What I'm saying is that it doesn't belong there. In the worst case, it may be the property of the DataSet, but... Karl Guggisberg napsal(a): Do you have a better suggestion on where to stick the selection cache or whatever we want to call it than in the DataSet? I think the selection cache (a collection of the currently selected primitives) should be maintained for each data layer (either by the layer or by some global selection cache which keeps a selection state per layer). If the dataset wasn't attached to a data layer why would you want to select/unselect objects? What I never liked is that there is a boolean field 'selected' on OsmPrimitive - this looks weired. ... exactly! Layer is the view of the DataSet. No view, no selection. Several views of the same dataset - maybe several different selections. Asking a primitive whether is it selected or not is a strange concept anyway. Why should it know? In which context? Imagine a tactical overview (a small view of the complete in-memory data rendered in the screen corner) or any other auxiliary view of the same dataset. You'd like to use the same rendering code, yet you don't want it to render the selected primitives the same way, for example. So I would go even further and deprecate/remove the selection notion from the primitive altogether. It is used in few places only anyway (beyond painting) and would be well served by a selection set on the Layer anyway. Regards, Nenik PS: In case you are afraid of the memory footprint of the selection set, you can borrow the Storage class from josm-ng. It will cost around 7B per selected entry (that is pretty small unless you select everything) depending on the target load factor and allow you to remove a boolean from OsmPrimitive (costing anything between 0 and 4 bytes per OsmPrimitive in memory, depending on several factors). Many more places in JOSM would benefit from Storage anyway (String cache in OsmReader, Long-OsmPrimitive maps in the OsmReader and the MergeVisitor, ...) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Reverse lookups
It is way faster than iterating through the data set. It's also much more
space efficient than keeping an explicit map.
For ways and nodes that's great and if we can speed up redraw() even the
better.
Reverse lookup for relation members is probably different. A spatial index
won't help here. We'll need a kind of backreferences from members to
relations.
-- Karl
-Ursprüngliche Nachricht-
Von: Dave Hansen [mailto:d...@sr71.net]
Gesendet: Freitag, 9. Oktober 2009 00:47
An: karl.guggisb...@guggis.ch
Cc: 'josm-dev'
Betreff: Reverse lookups
I've been using this code for a while to speed up JOSM validator tests:
http://www.mail-archive.com/josm-dev@openstreetmap.org/msg00265.html
What I do is just destroy the entire reverse lookup table each time the
DataSet changes. It works for batched operations, but reverts to sucking
each time that the data is modified.
I just experimented with replacing the explicit HashMapNode,ListWay with
something that uses the QuadBuckets search functionality instead.
It's pretty simple:
public ListWay waysUsingNode(Node n)
{
QuadBucketsWay qb = (QuadBucketsWay)ds.ways;
ListWay possible_ways = qb.search(n.getCoor(), 0.01);
ListWay result = new ArrayListWay();
for (Way w : possible_ways) {
if (!w.containsNode(n))
continue;
result.add(w);
}
return result;
}
It works because I calculate a bounding box for each node and all of its
nodes are guaranteed to be contained inside the box.
It is way faster than iterating through the data set. It's also much more
space efficient than keeping an explicit map.
BTW, here's the patch for using QuadBuckets for way storage:
http://josm.openstreetmap.de/ticket/3671
This could also potentially make click processing much faster. We can also
optimize redraw() operations when zoomed in on a large data set by doing a
search instead of iterating across the entire data set.
-- Dave
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] shocking - unsecure password sending!
Probably right although I'm sure a way can be found to save the user from having to cut+paste the token. I'm afraid, it can't. If JOSM was a web application, it would be part of the OAuth protocol that the OSM website calls back JOSM with the request token. For a java rich client this is isn't possible. But wait a minute, don't we a have a remote control plugin which is called back by the OSM web site? Yes, sort of. We would need - the OSM page which generates the request token to include a link a href=http://localhost:/oauth-request-tokenClick to import the request token into JOSM/a - JOSM to listen on port for such requests (similar to the remote plugin) This would be slightly less complicated from the users point of view but it's still not seamless. The user explicitly has to click on the link. -- Karl -Ursprüngliche Nachricht- Von: Frederik Ramm [mailto:frede...@remote.org] Gesendet: Mittwoch, 7. Oktober 2009 01:51 An: karl.guggisb...@guggis.ch Cc: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] shocking - unsecure password sending! Hi, Karl Guggisberg wrote: I think that people would be disappointed if one explained them how OAuth would work from JOSM. My understanding is, that it would work along the following steps: Probably right although I'm sure a way can be found to save the user from having to cut+paste the token. The request token can be saved in the JOSM-profile (agreed, that this avoids having userid/password unencrypted in the profile) and it will be used to get another access token the next time JOSM is started, but using OAuth doesn't protect us from sending uid/password in cleartext over the net. The difference is that since the token is valid forever, the unencrypted transfer of username and password will take place only once, and not with every request. (Requests would still contain the unencrypted token which would allow others to make edits in your name though.) But as I said before, I don't currently consider OSM accounts to be a valuable asset. I have many of them and should one be compromised then I'll create another. Any account created anonymously from the web page has the same privileges as my account so why should a hacker bother to hijack my account when he can just sign up for one? Thus I think the whole security question is more a kind of knee-jerk security paranoia thing than a real concern. (And anyone who cares so little about security that he uses the same password for OSM that he uses elsewhere does not really deserve that we make an effort to protect his data, does he?) This would however change if OSM accounts had special privileges. If my account could to things that yours cannot then that might make a difference. 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] shocking - unsecure password sending!
We have proxy authentication. But it seems there are situations where the passwords/usernames somehow gets mixed up. We don't have Digest Authentication and we don't have NTLM, and there are problems with the current support for proxy authentication. The proposed patch for proxy authentication with Basic Authentication using the standard header wasn't applied, as far as I remember. Why reinvent the weel? Luickly there are smart people providing http client libraries which would shield JOSM from the nasty details of proxy authentication, libraries which are tested against a heterogeneous set of proxy software in the wild. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Mittwoch, 7. Oktober 2009 16:24 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] shocking - unsecure password sending! On Wed, 7 Oct 2009, Karl Guggisberg wrote: From a technical point of view it would be wise to migrate the JOSM OSM API to the Apache http client, for two reasons: - it would be helpful in order to add proxy authentication (asked for since ages in trac) We have proxy authentication. But it seems there are situations where the passwords/usernames somehow gets mixed up. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] shocking - unsecure password sending!
Ah, so you confess that the Apache http stack is not *necessary* ;-) Yes, I confess, it isn't necessary in the sense that JOSM would stop working without it. Whatever JOSM wants to do, it can be done without the Apache http library. And, of course, there are other libraries around. My line of though was that new features often asked for would *benefit* from a http client library (they would be easier, faster to implement and easier to maintain). These features include OAuth and proxy authentication. And my assumption was that, although JOSM programmers could try to code whatever piece of software they need for JOSM, it would wise to rely on prebuilt libraries in order to get the features out. I confess, that this isn't a revolutionary idea either. As stoeckr points out, I might be wrong regarding proxy authentication. So far I thought we would *need* (in the sense that it couldn't be done withouth) a 3d party library for Digest Authentication and NTLM. The few OAuth client libraries I came across (just researching the web, no practival experience with them yet) relied on 3d party libraries, though, and for OAuth support it would be wise to rely on a library. But again, the better if somebody has an OAuth client library which has no dependencies to other libraries at all. -- Karl -Ursprüngliche Nachricht- Von: Frederik Ramm [mailto:frede...@remote.org] Gesendet: Mittwoch, 7. Oktober 2009 16:55 An: karl.guggisb...@guggis.ch Cc: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] shocking - unsecure password sending! Hi, Karl Guggisberg wrote: Why reinvent the weel? Ah, so you confess that the Apache http stack is not *necessary* ;-) Luickly there are smart people providing http client libraries which would shield JOSM from the nasty details of proxy authentication, libraries which are tested against a heterogeneous set of proxy software in the wild. Maybe JOSM could be built in a way to take advantage of a separately downloaded Apache HTTP client if one is there, and silently fall back to the built-in default if not? That way we wouldn't have to force all those libraries onto our users. Or else we can have a proxy auth plugin that people load if they want proxy authentication with all bells and whistles. That's one big gripe I have with the Java world. Instead of installing libraries in a global location on a system, every smallest Java program brings its own set of libraries because of course they all use a slightly different version of each. Bye Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problem with referrers
Hi there, jiri wrote: I'm not talking about history, I've just mentioned few cases where JOSM use copies of primitives. I think, framm got confused. framm wrote: you're trying to keep a breadcrumb trail of what happened to an object, I hope not! (although, this is the way the undo/redo mechanism is implemented today, sort of). jiri wrote: Prototypes will be probably used when parsing xml from API (instead of similar OsmData class that's already there). Then when you copy a node - properties of the Node will be saved to the NodePrototype and later new Node will be created based on that values. Yes, like today there's an internal class used in the OSM parser. It plays a role similar to that of the Prototype classes. jiri wrote: Prototype will be generated only when copy of some primitive is needed. So for example to allow undo in some actions or for CopyPaste action. Exactly, and just for the sake of naming suggestions: in this context they could be called NodeMemento, WayMemento, etc. (really just for the sake of examples, I'm not in favor of these names, they would be used in the context of undo/redo, but not in the general context of OSM primitives.). ImmutableNode, ImmutableWay? Not really, I think Jiri's prototypes are not meant to be immutable. In some software architectures there's also the concept of value objects (what's is sent from a remote client to a server) and value objects are sometimes called detached (from their entity objects). So would DetachedNode, DetachedWay, ... be an alternative? Today, whenever you need to walk from children to parents (from nodes to their parent ways, from members to their parent relations), you have to loop over all primitives in order to find the suitable parents. If you know that you will have a lot of child-parent relations to traverse you can build up the respective data structures and reuse them instead of looping over primitives. That's what BackreferenceDataSet and CollectingBackreferenceVisitor are used for. In the future this won't be necessary any more. Traversing parent-child will be as efficient as traversing child-parent. Child-parent relations will be maintained on the fly in the data structure we today know as DataSet. framm worte: Is the traditional setup not something like this: You have a model class which keeps the data, and then you have a controller class which performs all sorts of stuff on the models? I hope that no OO evangelist are reading this list because otherwise we are going to end up in a flame war about wheter and to what extend data and behaviour should be separated or not. I'm not talking about MVC here, OO evangelist would love that, but some (like Folwer) may call this separation of data and a controller which does all sort of stuff with the data an anaemic approach. framm wrote Another thing that may be worth considering at this time is whether you might want to separate out the display stuff. I've already started to do that, see getDisplayName(...). We had some discussions about this in a trac ticket, http://josm.openstreetmap.de/ticket/3261 -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Jiri Klement Gesendet: Montag, 5. Oktober 2009 19:29 An: Frederik Ramm Cc: josm-dev Betreff: Re: [josm-dev] Problem with referrers On Mon, Oct 5, 2009 at 9:43 AM, Frederik Ramm frede...@remote.org wrote: Can you explain (or point me to a previous post that explains) what referrers are good for? For example when way has list of nodes then every node has that way as a referrer. Also every primitive included in relation has that relation saved as referrer. Referrers are needed in lots of places in JOSM code, for example in DrawAction and DeleteCommand. It's obviously possible to get list of referrers by iterating over dataset but that's too slow for big datasets. Currently JOSM quite often makes copies of primitive (using for example cloneFrom or special constructors). It's not obvious whether the copy is added to the dataset or is kept in case we need to get back to old version of primitive (for example Command.cloneMap). That's a bit problem because I don't want to have such copy in referrers list, I want only primitives that are really used in an dataset. I'm trying to make sense of this (but might go off in the completely wrong direction here) - you're trying to keep a breadcrumb trail of what happened to an object, is that right? And you want referrer lists to model that family tree? But why can the list not simply reside on the other side, i.e. in the descendant object pointing back in history? I have the feeling that you're duplicating information by distinguishing objects that are really used in a dataset from those that aren't - should not the dataset itself be the ultimate arbiter on what is really used and what not? I'm not talking about history, I've just
[josm-dev] Critical bug since 2204
Hi everybody since 2204 there was a critical bug in Way. It broke the merge logic (the unit tests for MergeVisitor didn't pass). It is still present in tested (2221) and users will certainly notice because conflicts on ways are not detected as expected. Shouldn't running all unit tests be part of the build process, at least before a tested release is published? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please invest some time into documentation - especially confilict resolution
Hi Rolf, point taken, it's indeed necessary to get the documentation updated. But please also keep the actual users in mind when designing the UI, at least give the buttons some meaningful tooltips. Suggestions would be welcome. Which buttons should have better tooltip texts? What texts? Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Rolf Bode-Meyer Gesendet: Sonntag, 4. Oktober 2009 10:21 An: josm-dev@openstreetmap.org Betreff: [josm-dev] Please invest some time into documentation - especially confilict resolution Hi I'm thrilled developement goes on in good speed and central issues like conflict resolution have been already touched. Unfortunatelly end user documentation stays far behind. While simpler functions can be documented by experienced users, I fear the field of conflict resolution in JOSM is a riddle wrapped up in an enigma for most even experienced users. There was a post just yesterday where some people agree that they just push the buttons at random until the conflict is either resolved or the changes completely messed up. So please would those people who implemented conflict handling give detailed explanations in [[Help/Dialog/Conflict]] which currently is simply not helpful? Sure a dialog that needs no explanations at all would be best, and I understand that some things just aren't simple enough for simply pressing a button. But please also keep the actual users in mind when designing the UI, at least give the buttons some meaningful tooltips. Thanks, Rolf ___ 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] what does that button do
It resets the list of objects displayed in the Selection Toggle Dialog to the list of currently selected objects, although the Selection Toggle Dialog is supposed to always display the list of currently selected objects. We should remove the button, it looks silly. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von André Riedel Gesendet: Sonntag, 4. Oktober 2009 11:37 An: josm-dev@openstreetmap.org Betreff: [josm-dev] what does that button do 2009/10/4 Dirk Stöcker openstreet...@dstoecker.de: Asking specific questions here like what does that button do can help to solve troubles and the explanations can be copied into a doc. What does the 'Reload' button in the selection side dialogue do? Ciao André ___ 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] Please invest some time into documentation - especially confilict resolution
This is like the improvements in history dialog. One trac ticket with a simple suggestion caused Karl to make the history dialog much more understandable. It's not always that easy, but sometimes such hints can do miracles. Agree completely. We benefit from as precise suggestions as possible. Another example is this strange Reload button in the selection dialog which got mentioned today on dev. I think it was there since ages but nobody with svn access realized how useless it was unless somebody sent a short email (a trac ticket would have been even better). Personally I also benefit a lot from precise suggestions/defect reports provided by Avar. No. All my experience shows that this is untrue. People either help or they don't help. This goes along with my experience but the interesting point is how to find those who want to help. What do you have to do to attract people who would like to improve JOSMs documentation? I think today they don't even know that JOSM is looking for help. If we want documentation work to be done we should promote it. We can mention it on the JOSM home page as sub project, we can structure the work to be done, we can describe what we need, we can provide one or two good examples and tell people that we need more of the same. We can announce that we are looking for help on OSM dev, or on the german list for translation, for instance to achieve some small goal until end of october (i.e. complete documentation of the conflict resolution dialogs). -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Sonntag, 4. Oktober 2009 16:59 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Please invest some time into documentation - especially confilict resolution On Sun, 4 Oct 2009, Ulf Lamping wrote: JOSM translation shows that users are taking care if the hurdle for a first start isn't too high. Me feeling is that the help system The number of translators is so low, that I fear that does not qualify as real good example of user help. Also only about 6 languages are usually near 100%, the others are much below. 1. We need a josm-users mailing list. osm.talk (or local lists) are too polluted, josm-dev is not the right place for non dev questions (and dev probably prevents users from asking here). We currently don't have a place for a JOSM user community that could handle lot's of issues already at this place. Maybe we even need josm-users-de as there are lot's of german only JOSM users? I don't think there would be enough traffic for JOSM only users lists. The normal talk list are probably much better for this purpose. 2. Add meaningful tooltips for all GUI elements. This is by far the easiest and fastest way (beside a good GUI design) for people to learn a new GUI (at least that's true for me). While a lot of places already have useful tooltips, especially new GUI parts often missing this - where it would be most helpful. Here specific suggestions are required: What elements miss describing texts and what should the texts tell. This falls in the same group like Why do I need to click this and that, clicking this would be easier. The answer usually is: Because nobody ever thought about it that way. This is like the improvements in history dialog. One trac ticket with a simple suggestion caused Karl to make the history dialog much more understandable. It's not always that easy, but sometimes such hints can do miracles. For me users problems in mailinglists are no suggestion to document the way the software works, but they are a suggestion, that the software needs improvement. There are long-standing problems which need lots of work (like the still missing specific relation handlings) and others which only need finetuning. 4. Add the basic help steps yourself as a start. It's a lot easier for both sides (devs and users) to have a minimal help page to start to work from. If questions arise and the dev tells the user: Please have a look at URL xy. It's not perfect, it's a wiki, please improve it - that's a lot more helpful than just: do it yourself. At least my experience shows this is not true. Since I'm developing JOSM I tried multiple times. None of the stubs I wrote ever got expanded. Either there is someone caring for documentation or there is not. This is not the task of the developers, they are to valuable to continue development. For me programming is like walking - very easy. I learned that this is different for most other people and that only few people are really able to do good programming. I wont allow that these few people are scared away because they are forced to document their work more than necessary. Documentation is an independent task (not only for OpenSource, but also in larger companies). If nobody wants to document JOSM, then we have no documentation. As long as we try to improve the UI to be better
Re: [josm-dev] Please invest some time into documentation - especially confilict resolution
Karl could simply write down in a few sentences how the common workflows are to be done. No fancy screenshots or text formatting, so it can be done in less than 10mins. BTW: When you try to write it down, you'll probably already found some design mistakes :-) Sure. I today dig into the documentation stuff because I wanted to understand how it works. So, two samples from todays experiments http://josm.openstreetmap.de/wiki/Help/Dialog/History http://josm.openstreetmap.de/wiki/Help/Action/UploadSelection (here the documentation is ahead of the code - code to follow really soon ;-)) The context sensitive help in JOSM requires some clean up, too. For instance, currently it works in the JOSM main window only, not in modal dialogs, not in detached toggle dialogs, not in the history browser, etc. Today, I've fixed this too. And we also need some meta-documentation i.e. a short text explaining the how the help system works and what the structure of the online help looks like (there are pages for Actions, pages for Menues, pages for Dialogs, etc.). -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Ulf Lamping Gesendet: Sonntag, 4. Oktober 2009 23:54 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Please invest some time into documentation - especially confilict resolution Dirk Stöcker schrieb: On Sun, 4 Oct 2009, Rolf Bode-Meyer wrote: So please would those people who implemented conflict handling give detailed explanations in [[Help/Dialog/Conflict]] which currently is simply not helpful? You really need no programmer to write documentation. A good way to reach that goal would be to start writing that documentation and ask the developers to fix or continue wrong or missing parts only. For JOSM I think most processes or dialogues are quite simple and comprehensible. So only a few people need documentation and nobody writes it. Especially for the conflict stuff I think it really is needed and I'd write that documentation - but I'm lost as many else seem to be here. So assuming the one who developed it knows best how it works, I think at least this time it's a job for a developer. The problem is that these dialogs are Karl's design. He knows how they work best and that also means all is very plausible to him (for me too BTW). A very bad start when writing docs. Karl could simply write down in a few sentences how the common workflows are to be done. No fancy screenshots or text formatting, so it can be done in less than 10mins. BTW: When you try to write it down, you'll probably already found some design mistakes :-) Put it on the wiki and announce it to this list (or maybe directly to talk?) - asking for testing AND wiki improvements. This way, beta-testers know how the new feature is supposed to work and are now able to notice discrepancies between docs and implementation (aka bugs). (Side Note: This would have saved me a lot of very annoying time to figure out how the MapPaint Preferences Styles dialog is supposed to work!) Everytime someone asks about that feature simply point him to the wiki url (important: provide the exact url!). I have repeated experience, that this works much better than what we are doing now. And it's also much more fun for both developers and users. Best is when someone who does NOT know how it was designed writes docs. The errors he makes and the questions he asks are very valuable input for fixing design issues and also the result will be much more a documentation for beginners. Perfectly agree, that developers often don't have the skills to write good docs for beginners. So we again have a situation that many people have many opinions and all sides say you need to do it. Karl and all developers already did a lot. I always think it's time for the others to show they also want to contribute before I believe words like We continue after you start. H. We have a F1 feature that a little number of people know, a wiki that a little number of people know and no real communication channel for people wanting to involve (talk ml is way too high volume). Sounds like a communication problem to me! Looking at [1] I don't have the feeling that all users are just lazy ... Regards, ULFL [1] http://wiki.openstreetmap.org/wiki/DE:JOSM/Anleitung ___ 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] JOSM Tested
Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Freitag, 2. Oktober 2009 22:20 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested I wrote on Mon, 28 Sep 2009, please do not develop or checkin new stuff in next time so code can mature a bit (but do bugfixes instead :-). If no larger bugs show inbetween I would say the next tested version should be released next weekend. Ok, we had some critical bugs fixed this weekend, so I think the timeline should be expanded a bit to verify if fixes are correct. So expect next tested somewhen mid or end of next week. Are there any critical things left? I think no, but if you think so, then tell the bug report number. and now I have a problem. We had critical bug-fixes again which means another delay. But also if we continue this we wont get a tested at all, so I ask you all - Should a new tested be released sunday evening? 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. Great! Hopefully, this will make BackreferenceDataSet and CollectBackReferencesVisitor obsolete. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Jiri Klement Gesendet: Samstag, 3. Oktober 2009 11:48 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested I would preffer to have new tested released asap, the best would be releasing #2221 right now :-). I was hoping to be developing over the weekend. I'm going to add referrers (so you can eg get list of ways that reference some node). That should make some parts of josm much faster when working with large datasets. On Sat, Oct 3, 2009 at 11:34 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Ok, ok, my fault. I really thought this feature to be uncritical and worth to be in tested. We can make #2221 tested nevertheless if nobody sees troublesome bugs in it. 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 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] JOSM Tested
works for me, too, thanks! -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Samstag, 3. Oktober 2009 12:22 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM Tested On Sat, 3 Oct 2009, Karl Guggisberg wrote: Should a new tested be released sunday evening? I wouldn't do it. I'm not worried about #3459 and #3575, but like Claudius I feel that the new MultiSplitLayout needs more testing, see #3640 for instance. Fixed this one. Thought it was a bug in the MultiSplit code which I though has been tested otherwhere. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problem with referrers
Hi Jiri What do you think about that? Can you think of any problems this might bring us? I can only think of adavantages. The data classes I've added for managing the history of primitives could possibly be replaced with *Prototype too. The second approach (turning dataset into a factory for primitives) is fine for me too. Dateset.addNode(node parameters..) wouldn't be a static method on DataSet, but a method on a Dataset, right? I'd be happy to help migrating core and plugins to this new approach. Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Jiri Klement Gesendet: Samstag, 3. Oktober 2009 14:18 An: josm-dev Betreff: [josm-dev] Problem with referrers Hi, I'm working on support for referrers and I run into a problem which I'm not sure how to fix. Currently JOSM quite often makes copies of primitive (using for example cloneFrom or special constructors). It's not obvious whether the copy is added to the dataset or is kept in case we need to get back to old version of primitive (for example Command.cloneMap). That's a bit problem because I don't want to have such copy in referrers list, I want only primitives that are really used in an dataset. To workaround this issues I'm thinking about introducing new classes - PrimitivePrototype, NodePrototype, WayPrototype and RelationPrototype. These classes will hold informations for one primitive, but it will not be possible to add these objects to the dataset. That will allow to clearly distinguish what's real primitive and whats just an backup copy for for example Command.cloneMap or Main.pasteBuffer. Obviously it will be possible to construct new primitive based on prototype. Method cloneFrom() and constructoctors like Node(Node n) will be removed to make sure everybody is using new system. This will also fix another issue - for some features (most notably reliable events when primitive is modified) I need for every primitive to be part of exactly one dataset. This can be forced by making all primitive constructors protected and allowing to create new primitives only using methods like Dateset.addNode(node parameters..) or Dataset.addNode(NodePrototype). What do you think about that? Can you think of any problems this might bring us? -- Jiri ___ 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] QuadBuckets (using quad tiling) for node storage in JOSM
Karl, you followed that more intensive than I, when you want to apply it right now, then please do, so Dave needs not create a ticket. Actually, I got distracted, I didn't closely follow it. I'll leave it to you. Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Mittwoch, 16. September 2009 18:40 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] QuadBuckets (using quad tiling) for node storage in JOSM On Wed, 16 Sep 2009, Dave Hansen wrote: At this point, it doesn't *hurt* anything in JOSM. I'm not going anywhere and I'll be around to fix it up. As soon as we have proper OsmPrimitive change notifiers, I'll hook this code into it and we can start using it more widely. Could you please open a trac ticket containing the patch and a short description: - What it affects when applied - What it improves when applied I know about future, but what does it do now :-) Add [PATCH] to subject of patch. Karl, you followed that more intensive than I, when you want to apply it right now, then please do, so Dave needs not create a ticket. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [PATCH 1/2] QuadBuckets (using quad tiling) for node storage in JOSM
Hi Dave Any idea how you want this to look? I'm starting to code some primitive things, and it would be nice if I could get whatever I do merged eventually. AFAIK, nothing has been done so far. * Object updates are rare, and it is OK if the notification process is relatively slow * Rather than storing a list of all listeners that should be consulted on each object, store a (relatively) global list of listeners. Each listener would get all object updates for a particular type. That keeps us from having to store anything in *each* primitive. Currently, JOSM manages a list of data change listeners on *application* level. We'd need data change listeners per data set or per layer. Events should be emitted automatically, no call to fire... necessary by clients which update objects. Efficent batch processes are more and more important (see validator plugin, see upcoming changeset revert tools, see conflict resolution tasks), though, and it would be nice if data change event propagation could be used in two modes: immediate event propagation after an individual upate, event propagation after some kind of batch job has finished. I also want to have a ReverseLookup (node - ways) cache. I've had it sitting in the validator, but it's hard to keep it coherent and I end up throwing it away too often to make it useful. I recently hacked a basic revere lookup table for child/parent relationships (node - way, node - relation, way - relation, relation - relation), but it has to be build from a dataset on request, for instance before you start to fix 1000 duplicate nodes in validator. That's what the lookup table is currently used for (mainly in the new merge node action). Thinking about it, though... If we had ways in QuadBuckets, I probably wouldn't need the ReverseLookup cache. I'd just do a search for ways around a node and I'd just get the ways that are using the node back. Yes, but consider relation members too. That's where we often need reverse lookups. Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Coders: Please use true quotation marks
Hi Claudius
Value ''{0}'' is going to be applied for key ''{1}''
It's not as wrong as it looks. The strings are interpreted by the tr(...)
function which treats '' as ',
whereas as sinlge ' disappears. Users will see one ' only. Whenever you see
'' in I18n string, keep both in
the translation or I18n will fail.
In short: '' stands for ', not for
-- Karl
-Ursprüngliche Nachricht-
Von: josm-dev-boun...@openstreetmap.org
[mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Claudius
Gesendet: Sonntag, 13. September 2009 19:46
An: josm-dev@openstreetmap.org
Betreff: [josm-dev] Coders: Please use true quotation marks
I'm currently translating JOSM and stumble every now and then over strings
like
Value ''{0}'' is going to be applied for key ''{1}''
I understand that it's easier not needing to escape quotation marks, but
replacing them with two single quotes is plain wrong. So I'm addressing all
JOSM contributors to please check their strings for correct quotation mark
usage.
Thanks from the translators (and lovers of correct punctuation),
Claudius
___
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] [PATCH 1/2] QuadBuckets (using quad tiling) for node storage in JOSM
Just recently, Node/Way/Relation require access to be via accessor functions. That should help out quite a bit. The one thing that we do need is for a list of PrimitiveChangeListeners or something to call when primitives do change. This is the very motivation Jiri and myself have been working on replacing direct field access with accessors. Now we can start to work on features which will really improve JOSM, a spatial index for instance. -- Karl -Ursprüngliche Nachricht- Von: Dave Hansen [mailto:d...@sr71.net] Gesendet: Samstag, 12. September 2009 21:19 An: Petr Nejedlý Cc: karl.guggisb...@guggis.ch; 'Ævar Arnfjörð Bjarmason'; josm-dev@openstreetmap.org Betreff: Re: [josm-dev] [PATCH 1/2] QuadBuckets (using quad tiling) for node storage in JOSM On Sat, 2009-09-12 at 21:04 +0200, Petr Nejedlý wrote: Dave Hansen napsal(a): Ooh, I forgot about josm-ng. That one looks very usable. If mine doesn't pan out, I'll certainly look at that one. Well, the QTree in josm-ng is similar to yours in the way it distributes the content, though I did pay quite some attention to memory usage (hint: e.g. LinkedList is not the collection you'd like to use unless you have specific reason to) For the leaf nodes you mean? I actually got better performance out of it than I did ArrayList. Honestly, I've been looking at performance a lot more than pure memory usage, so I bet you're right. But, when you have an absolute ton of ArrayLists around that you're iterating over a lot ArrayList.size() actually shows up in the profiles pretty high. and support also 2d entities (node is zero-d). The problem with importing it directly into josm is that it uses (in -ng) the projected (and integer) coordinates. While it doesn't care whether the coordinates are projected or not, it hugely benefit from their signed integer nature. You just mean that they're cheaper to deal with than doubles/floats? Dave Hansen napsal(a): QuadBuckets also happen to implement CollectionNode. So, we can just plug it in for Collection like in the DataSet class. I have not looked at the josm codebase for a while, but as long as Node has publicly mutable coordinates, you can't honestly do it. If anything moves a node, it has no way to automatically jump into the new bucket. And it makes no sense to try patching all the places which can move a node (MoveCommand is not the only one). Just recently, Node/Way/Relation require access to be via accessor functions. That should help out quite a bit. The one thing that we do need is for a list of PrimitiveChangeListeners or something to call when primitives do change. You're right, though. This can't simply be dropped in for the node list and retain its searching abilities. -- Dave ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] why the new question?
Hi, There's a ticket in trac http://josm.openstreetmap.de/ticket/3200 which is most likely related to what you propose here. Could you please add a comment there? -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Russ Nelson Gesendet: Sonntag, 30. August 2009 18:14 An: josm-dev@openstreetmap.org Betreff: [josm-dev] why the new question? Why does JOSM now prompt me to save something which I've already uploaded, even though it was never saved in the past? Seems to me that this new change solves a problem I wasn't experiencing. Here's how I think it should work, which is how it used to work (as far as I know): 0) If I load a layer and don't change it, I should never be asked if I want to delete it. 1) If I download a layer from the web, change it, and upload it, I shouldn't be asked if I want to save it. If I don't upload it, I should be prompted You haven't uploaded these changes yet: UploadDelete, Discard Changes, Cancel 2) If I load a layer from a file, change it, and save it, I shouldn't be asked if I want to save it. If I don't save it, I should be prompted You haven't uploaded these changes yet: SaveDelete, Discard Changes, Cancel 3) If I load a layer from a file, and upload it, that will remove the internal modification marks. That counts as a change. See #2. 4) If I load a layer from the web, change it, and save it as a file, I shouldn't be asked if I want to upload it. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ 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
[josm-dev] josm.openstreetmap.de not working?
Hi, josm.openstreetmap.de seems to be dead. Can somebody have a look? -- Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Already deleted nodes one at a time
Instead of Uploading, try to *update* first using File-Update Data (or only File-Update Selection if you already know which primitives might create problems). This will reload all data in your dataset and for those nodes in your dataset which the server will not return it will check whether they had been deleted on the server (it will ask you first whether you want to run this check). For each such deleted (called invisible elements) on the server it will create a conflict which you will have to resolve manually. Resolve all conflicts and upload again. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Nakor Wikipedia Gesendet: Dienstag, 11. August 2009 22:35 An: josm-dev@openstreetmap.org Betreff: [josm-dev] Already deleted nodes one at a time Hello, I am trying to upload some changes and it looks like somebody worked in the same area and already deleted some nodes I edleted in josm. Each time I try to upload I get one conflict for that deleted node, have to re-upload again get a new conflict and so on Is there a way that I could get all those conflicts of nodes already deleted in one shot? Thanks in advance, N. ___ 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] Already deleted nodes one at a time
Yes, it may be a bit more complicated with deleted nodes. Search for modified (or search for deleted) in search dialog will show all modified nodes. The update these nodes with the update selected. Hmm, this shouldn't be necessary. UpdateDataAction compares with data.getCompletePrimitiveIds() which includes modified and deleted ids (and removes then the ID 0 for new primitives). Anything special with the dataset we discuss here? -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Dienstag, 11. August 2009 23:01 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Already deleted nodes one at a time On Tue, 11 Aug 2009, Nakor wrote: Thanks for your answer. However it looks like it did not solve my problem. I used FileUpdate data, no conflicts were found. I then reuploaded my file and one conflict on a deleted node was found. Yes, it may be a bit more complicated with deleted nodes. Search for modified (or search for deleted) in search dialog will show all modified nodes. The update these nodes with the update selected. That should help. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Already deleted nodes one at a time
There are some cases where conflicts should be resolved automatically: - server has deleted element and local element is deleted also -- delete - server has deleted element and local element is unmodified -- delete Yes, this should be an enhancement. I'd slightly reformulate it, though, because there are three different kind of deletes: - server has invisible element and local element is deleted- purge it - server has invisible element and local element is unmodified - purge it where - invisible - visible=false - deleted - deleted=true - unmodified - modified=false - purge - remove all references to the element in the dataset and either delete the primitive physically from the dataset or set visible=false (not sure whether the later would work in the local dataset, must of the code just checks for deleted not for visible; currently the code always phyiscally removes primitives from the dataset if it purges) -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dirk Stöcker Gesendet: Dienstag, 11. August 2009 23:33 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Already deleted nodes one at a time On Tue, 11 Aug 2009, Karl Guggisberg wrote: Yes, it may be a bit more complicated with deleted nodes. Search for modified (or search for deleted) in search dialog will show all modified nodes. The update these nodes with the update selected. Hmm, this shouldn't be necessary. UpdateDataAction compares with data.getCompletePrimitiveIds() which includes modified and deleted ids (and removes then the ID 0 for new primitives). Anything special with the dataset we discuss here? When we are on topic and Trac is offline: There are some cases where conflicts should be resolved automatically: - server has deleted element and local element is deleted also -- delete - server has deleted element and local element is unmodified -- delete 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM always on top
Are both you working with XP too? -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Michael Bemmerl Gesendet: Mittwoch, 29. Juli 2009 21:35 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] JOSM always on top Tobias Wendorff schrieb: Hi there, my v1869 is always on top ... is this a bug or feature? If it's a feature, how could I turn it off? Sounds like a bug to me. My JOSM is always top-most after uploading some changes. See this ticket: https://josm.openstreetmap.de/ticket/3128 Greetings, Michi ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM adds double ways to relations?
I only realised that there was two delete buttons last night. I think that there needs to be a better tooltop message, Any proposals for better messages? ... and icon to denote all or just that instance. Proposals for better icons would be appreciated too. Why do the two buttons need to be so far apart? Before there were two delete buttons in the botom row an we've got several tickets in JOSM trac because it wasn't clear enough in what sense they were different. They are no so far apart because they are placed in their context. The button on the left is close to the list of members. It deletes *all selected members*. The button on the right is close to the list of *selected primitives*. It deletes all members referring to one of the selected primitives. If I have to *explain* why they are placed where they are placed now the idea is obviously not intuitive enough, though. Any alternative proposals? -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Shaun McDonald Gesendet: Samstag, 25. Juli 2009 01:36 An: Lennard Cc: josm-dev Betreff: Re: [josm-dev] JOSM adds double ways to relations? On 24 Jul 2009, at 19:50, Lennard wrote: Maarten Deen wrote: That's a serious issue. I've seen that all the double ways appear in the edit relation box with -- or -- in the linked column. But if I then remove one of those lines, both ways get removed from the relation. Surely that is not intentional? I got bitten by that before, and the answer I got was: You're using the wrong delete button. I kid you not, I never noticed the other Delete button before that. :-) I only realised that there was two delete buttons last night. I think that there needs to be a better tooltop message, and icon to denote all or just that instance. Why do the two buttons need to be so far apart? But the relation editor received a major overhaul in the past weeks, so some things may not work as before, yet. Has someone already though of a distinct feature in the relation editor? Either a remove double entries or also a button add selected distinct entries? PS: s/double/duplicate/ -- Lennard ___ 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 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM without Main.ds
Hi,
Joerg must have quite an old snapshot of the source. Yes, Main.ds has been
removed recently, but OsmServerObjectReader.TYPE_REL has been replaced a
couple of weeks ago, as far as I remember.
I suggest to update from the SVN, clean and build.
-- Karl
-Ursprüngliche Nachricht-
Von: Frederik Ramm [mailto:frede...@remote.org]
Gesendet: Donnerstag, 23. Juli 2009 20:10
An: karl.guggisb...@guggis.ch
Cc: josm-dev@openstreetmap.org
Betreff: Re: [josm-dev] JOSM without Main.ds
Hi,
I have a new version of JOSM in which I got rid of the global Main.ds.
I hesitate to check it in, though, mainly because it won't work with
current plugins.
Has this been checked in? Because over on dev, Joerg Ostertag reports the
following compile problems, maybe someone can help him.
Bye
Frederik
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:228:
cannot find symbol
[javac] symbol : variable ds
[javac] location: class org.openstreetmap.josm.Main
[javac] Main.ds.setSelected(sel);
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:336:
cannot find symbol
[javac] symbol : variable ds
[javac] location: class org.openstreetmap.josm.Main
[javac]
DataSet.fireSelectionChanged(Main.ds.getSelected());
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:337:
cannot find symbol
[javac] symbol : method
realEqual(org.openstreetmap.josm.data.osm.Relation,boolean)
[javac] location: class org.openstreetmap.josm.data.osm.Relation
[javac] } else if
(!RelationEditor.this.relation.realEqual(clone, true)) {
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:339:
cannot find symbol
[javac] symbol : variable ds
[javac] location: class org.openstreetmap.josm.Main
[javac]
DataSet.fireSelectionChanged(Main.ds.getSelected());
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:429:
cannot find symbol
[javac] symbol : variable ds
[javac] location: class org.openstreetmap.josm.Main
[javac] for (OsmPrimitive p : Main.ds.getSelected()) {
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:448:
cannot find symbol
[javac] symbol : variable ds
[javac] location: class org.openstreetmap.josm.Main
[javac] for (OsmPrimitive p : Main.ds.getSelected()) {
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:511:
cannot find symbol
[javac] symbol : variable TYPE_REL
[javac] location: class org.openstreetmap.josm.io.OsmServerObjectReader
[javac] OsmServerObjectReader reader = new
OsmServerObjectReader(clone.id, OsmServerObjectReader.TYPE_REL, true);
[javac]
^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:513:
cannot find symbol
[javac] symbol : method parseOsm()
[javac] location: class org.openstreetmap.josm.io.OsmServerObjectReader
[javac] DataSet dataSet = reader.parseOsm();
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:516:
cannot find symbol
[javac] symbol : method editLayer()
[javac] location: class org.openstreetmap.josm.Main
[javac] .editLayer().data, dataSet);
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:523:
cannot find symbol
[javac] symbol : method editLayer()
[javac] location: class org.openstreetmap.josm.Main
[javac]
Main.main.editLayer().data.dataSources.add(src);
[javac] ^
[javac]
/home/tweety/openstreetmap-applications/editors/josm/core/src/org/openstreet
map/josm/gui/dialogs/RelationEditor.java:524:
cannot find symbol
[javac] symbol : method editLayer()
[javac] location: class org.openstreetmap.josm.Main
[javac]
[josm-dev] JOSM without Main.ds
Hi, I have a new version of JOSM in which I got rid of the global Main.ds. I hesitate to check it in, though, mainly because it won't work with current plugins. If you are a plugin developer/maintainer you may have a look at this class: http://svn.openstreetmap.org/applications/editors/josm/plugins/tageditor/src /org/openstreetmap/josm/plugins/tageditor/josm/CompatibilityUtil.java It provides a kind of compatibility layer to the tageditor plugin such that it runs in JOSM with and without Main.ds. You may consider to update your plugins in a similar way. If opposition isn't overwhelming I'll check in the new JOSM version by the end of next week. Expect it to be a little bit unstable, you may encounter a few NPEs. Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Integrating the map panel on another application
Hi, when I write unit tests for JOSM I also set Main.proj = new Epsg4326(); // if null nearly every construction of a Node // fails Or let josm.home point to a directory with a preferences file, i.e. System.setProperty(josm.home, /my/josm/home); Then I use Main.pref.init(false); // SIC: not true, otherwise whatever prefereces you have // are deleted -- Karl PS: the structure of JOSM would benefit from something called dependency injection. Just my two cents. -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Maria Arias de Reyna Gesendet: Montag, 29. Juni 2009 18:30 An: josm-dev@openstreetmap.org Betreff: [josm-dev] Integrating the map panel on another application Hi, I am trying to use the panel map integrated in JOSM (without the menus and the toolbars) on another Java Application, where I want to load a couple of osm files. I have found the MapViewer and the MapFrame classes, but when I try to integrate them on my JFrame, it crashes. I know that there are some preferences loaded on the Main class of JOSM and I am trying to replicate whatever the Main loads so I can use the map panel on my project. So far I have found this: Main.platform = new PlatformHookUnixoid(); Main.platform.preStartupHook(); Main.pref.init(true); which I think are necessary to load the map. After that I try: map = new MapView(); frame.add(map); and it works, showing me an empty map (black), although it says that the projection could not be read from the preferences and prints an exception: java.lang.ClassNotFoundException: at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.openstreetmap.josm.Main.preConstructorInit(Main.java:258) at my.application.Main$Initializer.run(Main.java:125) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java :269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:18 4) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) When I try to load an osm layer from a file: Layer layer = new OsmDataLayer(new DataSet(), prueba, new File()); map.addLayer(layer); It simply crashes, throwing this: Exception in thread AWT-EventQueue-0 java.lang.NullPointerException at org.openstreetmap.josm.gui.MapView.setActiveLayer(MapView.java:374) at org.openstreetmap.josm.gui.MapView.addLayer(MapView.java:173) at .my classes at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java :269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:18 4) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) I am wondering if someone can help me pointing me how can I separate the map panel from the rest of the application. If it is possible. I just need a map that shows osm files, nothing more. Thanks for your help :) -- María Arias de Reyna Domínguez Emergya Consultoría ___ 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] unit testing
OK, it's in the repository. Let me know if you need something else. -- Karl -Ursprüngliche Nachricht- Von: Dieter Muecke [mailto:d_mu...@me.com] Gesendet: Samstag, 27. Juni 2009 13:39 An: karl.guggisb...@guggis.ch Cc: josm-dev@openstreetmap.org Betreff: Re: AW: [josm-dev] unit testing I would focus on unit tests. Primarily all tests should run successfully after checkout from repository. Could you add missing libraries to svn repo? I've only found newer versions of the same. -Dieter On 27 Jun 2009, at 13:21, Karl Guggisberg wrote: Hi, I've only recently started to commit unit test cases, in a non- systematic way, thought. I strongly agree that there should be more test cases. I've been using the following framework(s) in test cases: - JUnit 4 - FEST (for reflection) I've started to write functional test cases too, mainly for automated GUI tests using FEST. My env is structured as follows test/unit - unit test cases test/unit/build.xml - ANT file for unit tests test/functional - functional test cases (including GUI tests and tests which require a running API server) test/functional/build.xml - ANT file for functional test test/data - test data for specific test cases (i.e. a set of merge test cases) test/lib/junit- JUnit libraries test/lib/fest - FEST libraries test/report - output directory for test cases I've committed a subset of this so far. If it was useful for you, I could commit the rest too. It's not very clean yet and it could be improved. So, I encourage you to work on this. Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Dieter Muecke Gesendet: Samstag, 27. Juni 2009 13:01 An: josm-dev@openstreetmap.org Betreff: [josm-dev] unit testing Unit testing seems slightly disregarded and I wonder why nobody has opened a jira ticket to fix? I would do the work if we would find an agreement which unit test library or framework to use. What are your thoughts? -Dieter ___ 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] Missing ways and additional conflicts
In the current JOSM it's doing two strange things: - if you download additional data after you have a first area downloaded (e.g. you pan a bit and need to bring in more stuff), it loses a few of the ways ... Confirmed. I first thought someone deleted the way (major street in our town). Ticket is here: https://josm.openstreetmap.de/ticket/2774 Unfortunatelly I can't reproduce it. If you have sample data please attach it to the ticket. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Peter Herison Gesendet: Mittwoch, 24. Juni 2009 20:33 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Missing ways and additional conflicts David Earl schrieb: In the current JOSM it's doing two strange things: - if you download additional data after you have a first area downloaded (e.g. you pan a bit and need to bring in more stuff), it loses a few of the ways ... Confirmed. I first thought someone deleted the way (major street in our town). - if you've made a change and do a second download which includes that changed object, you get a conflict. Confirmed. I only saw a difference in the last digit of one coordinate in the conflict-list. JOSM V1609 ___ 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
[josm-dev] Extended conflict resolution
Hi, r1631 now includes an experimental extended dialog for resolving conflicts, see http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/gui/co nflict The traditional dialog is still there and it is enabled per default. If you want to use the new dialog and its support for merging node lists of ways and member lists of relations you have to update your preferences: conflict.resolution=extended new, extended dialog is being used conflict.resolution=traditional traditional dialog is being used (no support for merging ways and relations) Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Conflict resolution doesn't work
there are several problems with conflict detection and conflict resolution in JOSM. Here's a patch for one special case https://josm.openstreetmap.de/ticket/2507 which is yet to be applied to the source tree. If the server version and the client version differ in the value of map feature and and if the user decides to keep his version conflict resolution doesn't work either. I'm currently working on this one. I also came across the case you're describing here. Sometimes JOSM detects a conflict although the conflict resolution dialog is basically empty. Don't know yet how to reproduce it - do you? Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Rolf Bode-Meyer Gesendet: Samstag, 2. Mai 2009 17:25 An: josm-dev Betreff: [josm-dev] Conflict resolution doesn't work Is the conflict resolution in JOSM supposed to work? Or may I do something wrong? On updating the data in an edited area I'm told there where conflicts and I get a relation listed in the Conflict panel. On clicking resolve a dialogue pops up but it doesn't show data in either of the three lists. Clicking resolve closes the dialogue, the entry in the panel is removed but on updating the data or uploading I get the error again. So what is it supposed to do, or is it not finished yet? Rolf ___ 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] Conflict resolution doesn't work
Hi, these tickets include descriptions on how to reproduce two conflict resolution bugs. See also attached patches. https://josm.openstreetmap.de/ticket/2510 https://josm.openstreetmap.de/ticket/2507 -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Frederik Ramm Gesendet: Samstag, 2. Mai 2009 19:14 An: Rolf Bode-Meyer Cc: josm-dev Betreff: Re: [josm-dev] Conflict resolution doesn't work Hi, Rolf Bode-Meyer wrote: On updating the data in an edited area I'm told there where conflicts and I get a relation listed in the Conflict panel. On clicking resolve a dialogue pops up but it doesn't show data in either of the three lists. Clicking resolve closes the dialogue, the entry in the panel is removed but on updating the data or uploading I get the error again. I fixed some conflict resolution bugs in version 1561 and tested basic conflict resolution afterwards and found it to work; if you can describe how to reproduce the above problem that would be great. 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 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
Hi, Uncommented changes are worth less than those with comments. Let's combine our efforts to make it as easy and comfortable for everyone to add meaningful comments, and we all gain from it. Here's a possible patch: http://josm.openstreetmap.de/ticket/2442 It still enforces a commit comment but it provides a default comment, either a standard comment or the users last commit comment. Regards Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Frederik Ramm Gesendet: Donnerstag, 23. April 2009 00:35 An: Ulf Lamping Cc: josm-dev Betreff: Re: [josm-dev] Commit message not empty Hi, Ulf Lamping wrote: My fear is that especially newbies are prevented from uploading stuff: what do I have to add here?!? - please remember: not everyone has several years of subversion or wikipedia experience. We'll add a help button to explain. Making the GUI complicated and adding a Help button to explain the complications is, well, not the best idea for improved user friendliness IMHO. A text field where you have to enter text is not a complicated element. Not the field needs explaining, we need to explain why we want users to fill the field with text. This is not a complication of the user interface, but a complication of the process how one can contribute to OSM. Whether or not entering a commit comment is mandatory - the complexity remains, and the need to explain to the user why we want him to enter one. The problem is that Potlatch has to open the changeset before the user has done anything. And while I am a great fan of commit comments, requesting that the user describe what he is about to do, before he has even done it, would be going to far in my eyes! So there is no way to really enforce the policy with an online editor. There is *no* problem to add a changeset to an online editor. This is simply just another indication that the potlatch model of not having a Save button is the wrong way to go IMHO. Yes, I should have said a live editor, not an online editor. Oh, and there will be no Yes and No buttons. You will have to type the word. Would you be very upset if I write a JOSM plugin that uses Potlatch to upload uncommented changes? ;-) Uncommented changes are worth less than those with comments. Let's combine our efforts to make it as easy and comfortable for everyone to add meaningful comments, and we all gain from it. 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 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] How to build plugins?
Hi, there was an error in the build.xml fo the tageditor plugin. I fixed it some days ago but the tageditor.jar in the dist directory is still broken. How can I test whether the build works? Can I invoke the build process myself? How? Regards Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Gray image from (e)wmsplugin/webkit-image
Hi all same here on Windows XP, but works great on Vista. -- Karl -Ursprüngliche Nachricht- Von: josm-dev-boun...@openstreetmap.org [mailto:josm-dev-boun...@openstreetmap.org] Im Auftrag von Marc Schütz Gesendet: Donnerstag, 25. Dezember 2008 18:31 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] Gray image from (e)wmsplugin/webkit-image I have updated all the components in question today (JOSM 1178, wmsplugin 12534, webkit-image from 2008-12-19, size 25088 bytes), even first deleted the wmsplugin.jar and the directory it has created from JOSM's plugin dir, so I'm pretty sure I'm using the newest versions. What version of QT4 do you have? Before 4.4.3 the Yahoo-Javascript failed sometimes. I'm using the one from your web site: http://www.dstoecker.eu/webkit-image.zip linked from here: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ewmsplugin#Windows Regards, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ 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] white stripes in latest YAHOO (webkit)
Hi Dirk works like a charm! Thanks a lot! -- Karl -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dirk Stöcker Gesendet: Mittwoch, 26. November 2008 16:45 An: josm-dev@openstreetmap.org Betreff: Re: [josm-dev] white stripes in latest YAHOO (webkit) On Wed, 26 Nov 2008, Tobias Wendorff wrote: I've just tried out latest ewmsplugin with YAHOO (webkit on Windows). In Dortmund (51.52, 7.46) I'm getting white stripes between the images. Also, the images are very distorted. I'm using Mercator-projection, like Yahoo does. Is there already a bugfix or are you working on it? Redownload the binary (Should have date 26.11.2008 for all files inside). That should fix the issue as I now found a proper way to handle resizing. 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 mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
