Re: [josm-dev] Tabular edit of name tags
Martin Koppenhoefer dieterdre...@gmail.com writes: 2013/6/26 Hans Schmidt z0idb...@gmx.de No, transcriptions/transliterations usually cannot be done automatically. There are so many irregularities or difficulties where it is not possible. You also have to account for creating spaces when there are none in the original example, the actual pronunciation is irregular (especially in Japan). Why should it not be stored inside the appropriate name tag? It should indeed then be stored in the appropriate name tag, but name:en is not appropriate ;-) name:ja:Latn seems a better choice (at least the concept, I have no idea whether this is the correct tag in this example) Transliterations depend on the target language, not only on the script. A transliteration of a Russian name might look different depending on whether it is done for a German or an English speaking audience. One known Russion composer's name is transliterated into Enlish as Tchaikovsky, into German as Tschaikowski, into French as Tchaïkovski, and into Spanish as Chaikovski (see Wikipedia). All these languages use Latin script. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Handling Openstreetmap account with shared computers
Pierre Béland pierz...@yahoo.fr writes: Under a HOT Team project in Limonade, north of Haiti, sixty young trainees share computers in a class room. In such a context, I want to assure that one person cannot use OSM identity of an other contributor when starting JOSM. What would be the possibility to assure this? A parameter at the start of JOSM ? I guess the best would be to setup user accounts for each user. You could have your users use OAuth. There, you can choose to not store the access token in JOSM preferences. See http://josm.openstreetmap.de/wiki/Help/Dialog/OAuthAuthorisationWizard Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] upload the same work several times
didier2020 didier2...@free.fr writes: Le dimanche 22 juillet 2012 à 12:20 +0200, Dirk Stöcker a écrit : On Sun, 22 Jul 2012, didier2020 wrote: my english is poor (sorry). users can load the same work several times like: http://www.openstreetmap.org/browse/changeset/12366293 http://www.openstreetmap.org/browse/changeset/12366372 can josm tell error to the user if same number of node or same sumber of way or same number of way and node had allready uploaded during the same session. it's difficult to detect that when it's done. This is only possible, when for some reason uploading fails. And in this case it is very complicated to detect for JOSM what has been uploaded and what has not been uploaded. In the long term this issue should be fixed, but it is not easy and happens seldom enough to be a major issue. thanks you anyway Just to elaborate a bit more: When you create new objects in JOSM they get temporary (negative) IDs. Then, when you upload the data JOSM sends those IDs to the server. The server processes the data and if it doesn't see any problems with it it assigns a permanent ID to each object with a negative one and sends all of these new IDs back to JOSM. JOSM in turn updates its objects in memory with the new IDs it got back from the server. This way JOSM knows the new data made it successfully into the database. For a larger amount of data the server processing stage might take quite a while. If during that time the internet connection of the client fails, the user hits Abort, there is a timeout, or anything else happens that causes JOSM to loose its connction the server might accept the data and load it into the database and JOSM won't know about it. On the next upload JOSM will upload the same data again. Therefore, it is a very good idea in case an upload fails or gets aborted to update the local dataset before trying to upload again. JOSM's Validator should then warn you about duplicate objects. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Stabilization ends
Jo winfi...@gmail.com writes: 2011/12/21 Dirk Stöcker openstreet...@dstoecker.de Hello, I can attach my config as a file to the ticket if you like, but in If that repoduces the error, do so. I'll have to try it first then. And delete any passwords that might be in there. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Is there any Debian package of osmosis available?
John Smith deltafoxtrot...@gmail.com writes: On 2 July 2011 07:12, Parveen Arora o...@parveenarora.in wrote: I think its only for natty Ubuntu, But I need it for Ubuntu 10.04 for higher which not seems to be available. Sorry for not mentioning this information in my previous email. It doesn't look like it appears in lucid-backports so you will most likely need to make your own package. I have not checked the dependencies for osmosis, but, if you are lucky, the package might be installable on an older version of Ubuntu. That is if osmosis does not depend on a package not in 10.04 (with a high enough version number). You can try to download the package and install it manually. Your package manager will tell you if there are unmet dependencies. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Suggestion for the upload window
Carsten Gerlach daswaldh...@gmx.de writes: in the upload window there are three parts for objects to add, objects to modify and objects to delete. Is it possible to sort the entries inside this parts according node, way and relation? At the moment there is a wild mix, as you can see in the attachement (at least in the modify part). Please open an enhancement ticket at https://josm.openstreetmap.de/newticket Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Taggen von übereinanderliegenden Ways in JOSM erkennen
Holger Schr@der mailingliste...@web.de writes: Gibt es im JOSM eine Möglichkeit schnell zu erkennen, ob Nodes mit doppelten Ways verbunden sind? Wenn nicht, ist daran gedacht dies zu implementieren? Es ist vielleicht nicht ganz, was Du suchst, aber JOSM zeigt alle übereinander liegenden Wege an, wenn man mit der mittleren Maustaste daraufklickt. Dies ist übrigens eine englischsprachige Liste. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Oneway display
Nakor nakor@gmail.com writes: Hello, Is there a way to go back to the previous oneway display? The new one is very confusing because: * all ways looks like they are oneway (having their arrows displayed all the time) You can turn way direction arrows off in preferences: Display Settings -- OSM Data Maybe they should be off by default? You can also choose whether you want theese arrows at the end of each segment or only at the end of each way. * at higher zoom levels the black triangle is not displayed making oneways looking like they are not. I suppose, with higher zoom levels you mean a greater number on JOSM's scale indicator? (which actually means a lower scale.) The oneway arrows are placed in regular intervals on screen. When a way is shorter on screen than that interval there is no oneway arrow displayed. I guess this has been this way since oneway arrows (the black triangles) were introduced a while ago. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Oneway display
Nakor nakor@gmail.com writes: Is there a way either to display the arrows at the node on the oneways like before or to make sure that there is at least one triangle displayed in the middle of the way when it is too short? Please open a ticket for this. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] translating in Launchpad
Jo winfi...@gmail.com writes: Hi, I'm working on the translation of strings towards Dutch in launchpad. I noticed that some strings have comments. With English being a language where one spelling of a word is very often ambiguous, it would help a lot to know what part of speech a given term is: Content can be a noun or an adjective and of course the translation of either is completely different. [...] Can I add to these comments somewhere myself? In order to disambiguate them? Also, what if I find an error in the English string? Can I report that somewhere or can I correct it myself directly? The English strings and the comments are in JOSM's source which you can find in SVN: http://josm.openstreetmap.de/svn/trunk/ Errors in strings or ambiguities should be reported by filing a ticket in trac: http://josm.openstreetmap.de/newticket This can be done anonymously, but, it is much better if you login first because then you can be contacted in case there are questions. You get bonus points if you directly attach a patch to your ticket. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] where are the slippy-map settings to switch bing imagery ON
ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl writes: This seems not to be so obvious and the help is not very helpful here I read both have been combined (WMS / slippy) in one josm core integrated imagery menu, and indeed I have that, But it contains only a list of the servers I used in at the time of the Haiti project as well as a few others such as Yahoo. No BING url ? If I have to enter it myself, I would be happy to know which one In the preferences there is a tab for the imagery settings (WMS TMS). There at the top is a list of available imagery providers. Do you have Bing in there? If not you can try the update button next to the list. If you have Bing in the list you can select it and hit the Activate button below and hopefully that will make Bing available from the Imagery menu. Anyway, the URL for Bing is bing:bing. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] validator question, multipolygons
Lennard l...@xs4all.nl writes: On 5-3-2011 18:37, Mike N wrote: On 3/5/2011 12:05 PM, Russ Nelson wrote: I agree. What might work for better nannying is to only run the validator on things they've changed. Otherwise they get asked to fix everything within the bounding box they downloaded. ? It already works this way for me. When you hit upload, yes. If you click Validate in the validator, it checks every object. ... if nothing is selected. Otherwise it checks the selection. I quite like that behavior. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Remove 'Export to GPX...' from File menu
Dirk Stöcker openstreet...@dstoecker.de writes: On Mon, 21 Feb 2011, Sebastian Klein wrote: I'd like to remove the menu entry 'File Export to GPX...'. It is always disabled, unless a gpx layer is the *active* layer. Hmm, shouldn't it be enabled for OSM and GPX? Can JOSM convert OSM data into GPX? Exporting GPX data to GPX is somewhat strange. What is the difference between Save and Export to GPX? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: Filter Google from Imagery?
Matthias Meißer dig...@arcor.de writes: Now with Bing there is a good alternative, so only a few 'hardliners' would like to do so, to make the current ultimate map of their area, with fresh material. I guess this guys are able to setup a proxy to do so. It's IMHO not on us to make sure that they use the right aerial imageries. There are still many areas where Google's imagery is a lot better than Bing's. Like right here where I live Bing imagery only goes to z13. Yahoo's images are already a lot better and allow some tracing. But, the best by far are Google's. The temptation is certainly still there. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Sticky Tags Feature
Russ Nelson nel...@crynwr.com writes: Frederik Ramm writes: I'd like to implement a feature in JOSM that applies the tags from the clipboard to every new way or node created. I think this would be useful for creating powerlines (apply power=tower to every new node in the way) or for a set of buildings along a street (addr:street=* to every new building). A graphics program i used to use, maybe it was dia?, worked like this: whenever an object was selected and you changed properties, you were changing the properties of that object. When no object was selected, you were changing the default properties for new objects. Oooh! Ooooh! Much simpler than my Presets proposal. Only problem is that it might confuse newbies. Maybe put it in a different color or font to let them know that they're setting a different kind of property? JOSM already has a command Paste Tags (Ctrl+Shift-v) where it adds the tags of a copied object to all currently selected objects. That key stroke is a bit of a stretch to do with one hand. But, if you assign a single key to this command I guess this might get you pretty far to what you want to do. Then, you can simply draw with one hand and hit the keyboard with the other. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Tools menu too long when plugins installed
Ulf Lamping ulf.lamp...@googlemail.com writes: Am 27.11.2010 18:04, schrieb Frederik Ramm: Sure, every solution has it's drawbacks. But what's the users interest? To know which menu item is caused by which plugin, or to intuitively find a functionality where a user expects it. If you have just asked for something on the list, and people have told you install the XYZ plugin, then you can do what you want, I think it would not be too much to ask from the user to go to the Plugins/XYZ menu. Indeed this provides a clear visual clue that the XYZ plugin is indeed installed and active. If the plugin doesn't have/need a menu entry, this logic fails :-) I don't think the real user interest is to make sure that a specific pugin is installed. I think the user simply wants to use the function in question. And if the functionality of plugin XYZ can be found in Plugins/XYZ it might be the most reliable way to find that function - if all plugins behave like that. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] changeset comment length limitation
On Tue, 9 Nov 2010 19:10:26 +1100, Andrew Harvey andrew.harv...@gmail.com wrote: Linking to somewhere on the wiki seems like a good idea, I think instead I'll just add my changeset comment as a diary entry and link to the diary entry in the changeset comment. At least this allows people to discuss a given changeset further (something I've wanted to be able to do myself in the past without needing to send a private message). And if osm.org/browse/... would detect URLs in changeset comments and make them clickable that would make it even more convenient. Or, the URL can go into a separate tag. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] changeset comment length limitation
On Tue, 09 Nov 2010 09:15:13 +, Tom Hughes t...@compton.nu wrote: On 09/11/10 08:47, Matthias Julius wrote: And if osm.org/browse/... would detect URLs in changeset comments and make them clickable that would make it even more convenient. Or, the URL can go into a separate tag. A bit like this you mean? http://www.openstreetmap.org/browse/changeset/6325940 Exactly! I'm impressed how quickly the feature got implemented. :-/ Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Tagging] Super-relations or not
On Tue, 2 Nov 2010 01:02:37 +0800, Eugene Alvin Villar sea...@gmail.com wrote: On Tue, Nov 2, 2010 at 12:25 AM, Peter Budny pet...@gatech.edu wrote: As far as I'm concerned, the difference in what's required to tag things is minimal between these concerns. Therefore, wouldn't it make the most sense to choose whichever is programmatically the easiest and most flexible to deal with? It depends on what the you want to use route relations for. It's quite possible that different uses would demand different ways of structuring the route relation(s). I would sey they should be set up that is best for mappers to deal with. Software can be made to deal with any scheme as long as there is a consistent scheme. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
On Thu, 28 Oct 2010 22:24:56 +0800, Eugene Alvin Villar sea...@gmail.com wrote: The easiest way is to get the shortlink URL and append ?m to the end. And the next easiest way is to get the permalink and add m in front of lat and lon. But, the challange is to get lat and lon right. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] i18n update issue
On Thu, 28 Oct 2010 11:28:23 +0200, Frederik Ramm frede...@remote.org wrote: Hi, On 10/28/10 11:01, Claudius wrote: There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: I must have been busy with something else when OSM made the jump from mapping the world outside to managing household appliances. I guess people have started to micro-map their apartments now. Or is it about stuf you might find at fuel stations? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Data source for robot
On Tue, 12 Oct 2010 10:48:29 +0200, Jochen Topf joc...@remote.org wrote: On Tue, Oct 12, 2010 at 04:36:34AM -0400, Peter Budny wrote: They /are/ required, because roads may be discontiguous in various ways: a road may change names (e.g. Main Street North becomes Main Street South, but to a driver or pedestrian, both are just one continuous Main Street), or even be physically discontiguous (some state and even US Highways do this). So? Is any application actually using this? And what for? I am not beeing facetious, what are these routes actually useful for that the tags on the roads don't already do? It avoids duplication of data. You can either have the same tag on 200 road segments or on one relation. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.7+: Split node concept?
On Tue, 12 Oct 2010 22:19:15 +0200, Frederik Ramm frede...@remote.org wrote: Hi, Chris Browet wrote: I am wondering (I wonder a lot lately ;-)) if some have already given a thought to the fact that nodes actually represent 2 different concepts Yes, this is something that has been discussed on and off for at least two years. I know because we mentioned in the first edition of our OSM book ;) Of course the node element would have to be kept not only for POI nodes but also for topology nodes (where two ways meet). Having geometries in ways would be much more traditional-GIS-like and would simplify many things. However your suggestion mixes in-way geometry with geometry by reference to nodes; and it has to because otherwise you lose topology. But this means you don't get the full advantages of either. A big potential problem I see is promoting and demoting nodes - you select and tag a point in a way, thereby creating a node; you later remove the tag from the node, thereby deleting a node. You let a road and a forest boundary share geometries, thereby creating proper nodes for each shared coordinate; you split them apart, deleting the nodes and creating two sets of points-in-ways. I see the basic idea but it all seems a but uneven to me, even ugly to implement. Maybe less ugly would be to have nodes just contain lat and lon and introduce new point elements that need to reference a node. That would also make it easier to put two different objects at the same spot (like a mail box on a lamp post) as added benefit. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Completeness of the country dumps
On Mon, 27 Sep 2010 14:14:39 +0200, Frederik Ramm frede...@remote.org wrote: Hi, Zbynek Winkler wrote: even thought the missing things are within the export bounding box Geofabrik extracts are polygons, not boxes! http://wiki.openstreetmap.org/wiki/Planet.osm/FAQ says that ways are trunkated at the border. Is there a dummy node inserted at the intersection with the bounding polygon? Or is the first node outside the border included? In either case I suspect there are problems with merging two of those extracts (with osmosis --merge) due to two ways with the same IDs. Am I missing something? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Change to changeset comment handling, RfD
Frederik Ramm frede...@remote.org writes: Hi, ce-test, qualified testing bv - Gert Gremmen wrote: I suggest we try to JOSM add some comments by itself: Merkaartor did that, or perhaps does it still. These auto-generated comments are next to worthless. They cannot replace one human being telling another human being in a few words what has been done and why. Especially the why part would be hard to guess for any program. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to resolve conflicts?
Dirk Stöcker openstreet...@dstoecker.de writes: JOSM never had a detection to find that new elements in editor are equal to elements on the database. As soon as upload went well for the server, but josm doen't get informed about there is a problem. We don't have a match new stuff to server stuff and drop it when equal. This would be required to fix this issue. Actually, JOSM does something like this when merging new objects (id 0) into another dataset. So, to get JOSM to map new objects to objects downloaded from API after there have been more modifications to the dataset it might work to : - download the area into a new layer - merge the old layer into the new one On the next upload you will get conflicts for objects that have been deleted in the local data because JOSM tries to delete them again on the server. There might be other pitfalls. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to resolve conflicts?
Dirk Stöcker openstreet...@dstoecker.de writes: What to do: When you have this situation that upload may have aborted after the elements got accepted by server: - Download the same area in a new layer. - Check if your changes exist there as well. Yes: Drop the layer with the original changes. No: Upload again, as first upload failed. Unfortunaltely, this is not so straighforward if you did a chunked upload and the upload failed before the last chunk was sent to the server. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to resolve conflicts?
M∡rtin Koppenhoefer dieterdre...@gmail.com writes: 2010/7/19 Matthias Julius li...@julius-net.net: M∡rtin Koppenhoefer dieterdre...@gmail.com writes: What are you trying to upload? normal edit, mostly created from scratch. Re-uploading new objects never creates conflicts. Only modified (including deleted) ones do. It will only create duplicate objects on the server. If you try to upload right after the failed upload you will get conflicts for modified objects because their version number had been incremented on the server during the failed upload. yes, but I also got the error while doing the _first_ upload. Well, if your data conflicts with the server's data (usually because someone has uploaded an object you have modified) then there is no way around resolving those conflicts before the server will accept the data. But, if you can verify that your data has been accepted by the server you can throw away your old dataset without trying to upload. Yes, I'm doing this, but if _some_ data was uploaded and some wasn't, this gets painful to detect ( I tend to _believe_ that everything went well, when it looks so at first sight). Normally, uploads are atomic. Either the server accepts the whole upload, or not. It only can get problematic if you did a chunked upload as mentioned in my other mail. And if the server has rejected the upload because of a conflict then none of the data made it into the database and you need to resolve the conflicts first. Unfortunately, the server returns an error as soon as it encounters one conflicting object. JOSM has no way of knowing whether this was the only one or whether there are lots more. Depending on the individual case the most economic way of resolving those conflicts might be to select all modified objects and the to Update selection and to resolve any conflicts that come up. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New feature
Markus marku...@bigpond.com writes: Hello, I am impressed with the work being done on JOSM. Thankyou. I am wondering if it is possible, that the uploading changeset data box include a percentage done. Not in a meaningful way. During upload most time is spent by waiting for the server response and JOSM has no way of knowing the progress of the server processing your data. The actual upload does not take all that long. What could be done in principle is to change the status text to Waiting for server response ... or so to indicate that all data has been sent. When hitting Cancle after that JOSM could display a warning that the upload actually was complete and that there is a high probability that the data will show up in the database and that JOSM's data is likely out of sync. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Nearest way for a location
Stephan Plepelits sk...@xover.htu.tuwien.ac.at writes: On Sun, Jun 27, 2010 at 07:11:53PM -0500, Nolan Darilek wrote: 3. In dusting off my disused (and never that good to begin with :) math skills from over a decade in my past, I'm thinking that a vector-based solution might work. I am already calculating a node's neighbors if it is on one or more ways, so I think that if I create vectors between the nearest node and each of its neighbors, then determine which segment has the least distance to the user's current location, then I've figured out the user's new way with minimal complexity. Before I go off and implement this (or rather, before I figure out which vector operations apply here and *then* implement this :) can anyone tell me why this may be a bad idea? I think this is a very good idea :) Check out the Hesse normal form[5] how to calculate the distance of a point to a line. The nearest road does not need to have a node near your location. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Extending Undo
Sebastian Klein basti...@googlemail.com writes: Upliner wrote: By the way, what do you think about making merge layers operation undonable? I think I can implement it, there is some groundwork for in reverter and fuzzer(ext_tools) plugins. Cool. I see 2 paths here: First would be to have an undo stack for each data layer. Normally there is no reason you have to first undo all later operations on layer b before you can undo things on layer a. (Although I never had that problem.) Second, make higher level layer operations undoable. (Only thing that should be excluded is toggle of active layer and visibility.) Undo of merge layer would probably the most useful extension here. A layer merge is essentially two operations: first merge the data into the target layer and then delete the source layer. The first part would be covered by the target layer's undo stack. The second could be left to the user. JOSM could simply not delete the source layer. The problem with making such operations undoable is that this potentially requires a lot of memory if there is a lot of data involved. We might need to think about storing such things on disk. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] How to earn undying fame
Nic Roets nro...@gmail.com writes: The result of the uservoice survey[1] is in: The community wants routing on our website more than anything else. [...] The routing database can be updated weekly. It might make for a strange user experience if a different version of the data is used for routing and rendering. Also, the value of the routing service for debugging purposes would increase significantly if the routing database would follow the minutely updates. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] JOSM-Tested
Claudius claudiu...@gmx.de writes: Talking from a translator's (contributing to other projects as well besides JOSM) perspective: I don't see the need for a string freeze and am totally okay with way l10n is currently handled in a live manner. I just would like to avoid that translations are invalidated by a string change just before a release. A link to Launchpad already is on the MoTD page. We could also include one in the About dialog to enable people to find it later. There could also be one in each dialog when a translation into the current locale was not found. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM-Tested
Dirk Stöcker openstreet...@dstoecker.de writes: On Fri, 11 Jun 2010, Matthias Julius wrote: It might be a good idea to declare a feature and string freeze and issue a call for translation updates for a few days before each testing release. This would give translators a chance to catch up. It might also boost their motivation a little bit when they know that their perfect 100% translation actually will make it into a release. Are there any translators on this list? How would you like that to be handled? Yes. I'am. I always tell me before release that everything must be translated. Usually I try to do so :-) That's a good first step. Now, you just need to tell the other translators as well. ;-) No really. Usually in the time after announcing tested stage first time only bug-fixes are done and they don't usually add new user visible strings, but mainly error messages or the like (or new plugin strings). I also take care that the translators have a chance to catch up before, so the languages which currently try the 100% (German, Ukrainian, Russian, Italian, ...) have the chance to do so. All I am suggesting is to make this a bit more explicit by saying something like Translators: please update your translation now if you want it to be in the next release. Developer: please don't make any major changes and don't change any translated strings. in your announcement of an upcoming release and give a deadline for this of a few days. Of course, this only helps if translators get to see the announcement. On the other hand JOSM is in flux always, so texts in updated plugins become outdated and many language miss newer strings anyways. Until now it seems impossible to get a release handling for JOSM translations. There are always only few people who really actively translate texts and most languages stay in the incomplete state. And there are really many strings in JOSM and always comming a lot of new strings. It is a bit weird that plugin localisation is done in JOSM core, but this is a different can or worms. I know this situation from other projects and it seems it is unsolvable, so I don't really want to stop development because of missing translations. Only solution would be a release branching each time we hav a tested, but due to various reason explained in length in other mails I still don't think the currently working josm process should be changed without need. We don't really have to stop development, but maybe we can restrain from introducing new features for a few days. Bug fixes are always welcome as long as they don't change translated strings. Maybe we could just not update Launchpad for a week or two after a -tested release. And if there are significant improvements in translations after that time we can still consider creating a branch and update the translations in -tested. This does not mean that when there is a chance to better motivate our translators we shouldn't try it. We can speculate about what would motivate translators forever. It would be good to get some input from actual translators (besides yourself). Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM-Tested
Frederik Ramm frede...@remote.org writes: Hi, Matthias Julius wrote: We don't really have to stop development, but maybe we can restrain from introducing new features for a few days. Bug fixes are always welcome as long as they don't change translated strings. Developers must never be held back from doing what they have to do by translation. If a bug fix requires that a string be changed, then the string must be changed. Even if it is just a minor thing like an alert popup that is worded badly so people tend to misunderstand it - we cannot hold back improving the software just because the translator for Ancient Greek is on holiday. I am not saying we should hold development until all translations are complete. I would just like to give translators a chance to get their translation into a released JOSM. I imagine it could be very frustrating to find that a string shows up untranslated just because someone felt that a comma needed to be added. Do you think holding back string changes for a few (maybe 3?) days will disrupt development too much? The other question is of course whether there would be a significant improvement of translations accomplished within only a few days. If people would rather have a software with more bugs but where everything has been translated, than one with less bugs but where some things are untranslated, then we really have to do branches for language versions. Not every bug fix requires a string change and not every bug in strings is grave enough to invalidate all its translations in an upcoming release. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM-Tested
Dirk Stöcker openstreet...@dstoecker.de writes: In my eyes the current release is more stable and bug-free than any release before, so tested can be set. Except in case translators do major texts today I would vote for making todays nightly build tested tomorrow. It might be a good idea to declare a feature and string freeze and issue a call for translation updates for a few days before each testing release. This would give translators a chance to catch up. It might also boost their motivation a little bit when they know that their perfect 100% translation actually will make it into a release. Are there any translators on this list? How would you like that to be handled? Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] openstreetmap.de down
The whole openstreetmap.de domain is not reachable at the moment. It seems to have disappeared completely from DNS. Are there issues with the provider? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] openstreetmap.de down
Matthias Julius li...@julius-net.net writes: The whole openstreetmap.de domain is not reachable at the moment. It seems to have disappeared completely from DNS. Are there issues with the provider? The same is true for geofabrik.de. Did Geofabrik go belly up, or what? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another 66 relations bite the dust
Sebastian Klein basti...@googlemail.com writes: Roland Olbricht wrote: [1] http://trac.openstreetmap.org/ticket/2652 You can get an approximate solution: http://78.46.81.38/api/rels-extended?id=34631 This points to the OSM3S server and returns the desired relation-ids for the given relation id. But still this would be a great step from deleting relations accidentally. No, this particular problem generally does *not* cause accidental deletion of relations! The worst that can happen is someone splits a way and does not add the new part into the relation (because he does not know about it). Then a multipolygon is no longer closed and does not render ... something like that. Also, if the user operates inside the downloaded bbox, everything is fine. The issue comes into play when editing boundaries and other large scale objects. A while ago I was toying with the idea of having JOSM track for each primitive whether or not it knows about its parents. AFAICT it should only know with some certainty if the primitive was downloaded inside the bounding box of a map call or if it has asked the API explicitly. Then it could show a message like: This object might have parents that have not been downloaded from the server and that might be affected by this operation. How do you want to proceed? Cancel Ignore Download parents Optionally JOSM could also check the server automatically for parents. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How does priority setting work ?
colliar colliar4e...@aol.com writes: Hi Sorry for setting priority of todays bug on blocker. Was wrong. I noticed that a lot of bug priorities were changed and I sometimes wonder why (maybe we should add a comment each time we change it). Please tell me your opinion. If a bug is blocking me from working me with latest but it is not present in tested, I consider it as a blocker. If a bug is destroying data I consider it as critical. A bug that blocks you from doing something might not be relevant to many other people. Also destroying data can mean different things. Just try to picture the relevance to the JOSM users in general and not only to your special case. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Where are the slippy map chooser tiles cached?
Lennard l...@xs4all.nl writes: On 8-4-2010 23:31, MP wrote: No. This is where WMS tiles are cached. Slippy map chooser caches it in temporary directory (/tmp on unixes, %TEMP% on Windows machines, which is usually C:\Documents and Settings\Username\Temp) and it creates JMapViewerTiles_Username directory there in which it stores the cached tiles. On my machine, I can find them in: %USERPROFILE%\Local Settings\Temp\JMapViewerTiles_%USERNAME%\Mapnik The way the tiles are stored (all in a flat dir) makes any file operations in the Windows Explorer (in XP) almost impossible, because it incurs very long delays in processing the dir. Mine a few weeks after clearing: 41877 files, 174700223 bytes Fortunately, clearing them from the command prompt is still fast. I wonder why they cannot be stored one dir per zoom, or in another hashing format. Because nobody has implemented that. Under Linux this is usually not a problem because /tmp typically gets cleaned out at boot time (at least on Debian it does). I wonder if JOSM should delete the cached tiles on exit. Is deleting the whole directory just as slow? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] A simple way to switch advanced settings?
Claudius claudiu...@gmx.de writes: I'd love to switch mappaint.useRealWidth true/false via the toolbar. Do I need to write a plugin to do so? A patch might do, too. I don't think it is necessary to write plugins for trivial things like this. Matthias ___ 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 ?
Dirk Stöcker openstreet...@dstoecker.de writes: On Mon, 8 Mar 2010, Matthias Julius wrote: 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. Since a while I have been thinking adding Take mine and Take theirs to the context menu of the conflict list dialog. Even quicker would be if the conflict list dialog had buttons for this. Be careful with this. It should only be offered for simple conflicts. What is a simple conflict? A graphical visualization of both sides of conflicts would help. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] how does the transition to tested work ?
Karl Guggisberg karl.guggisb...@guggis.ch writes: 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. Since a while I have been thinking adding Take mine and Take theirs to the context menu of the conflict list dialog. Even quicker would be if the conflict list dialog had buttons for this. I didn't do anything in that direction, yet, because we are trying to stabilize JOSM. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] deleted vs. visible
I need to brung up this subject again. I still can not wrap my head around why we need to distinguish between deleted and visible state for primitives and bother the user with it. AFAICT, isDeleted()==true is equivalent to isVisible()==false isModified()==true. I believe there is currently no way to have primitives with either isDeleted()==true isModified()==false or isVisible()==false isModified()==true. Therefore, I think the two flags can be consolidated. IMO, it is enough to have the DELETED flag and to distinguish between deleted locally and deleted on server the MODIFIED flag should be enough. This would simplify both merging and conflict handling. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
Dirk Stöcker openstreet...@dstoecker.de writes: Hello, even if I'm still not 100% happy with current JOSM I would think we should make 3070 tested, wait for reports and maybe make comming saturday version tested again and afterwards start with new development. Comments, objections? I guess it is an improvement over the current tested in any case. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] deleted new primitives
Ticket #4522 is about conflicts when merging new primitives that have been deleted in one dataset. I am wondering why do we keep deleted new primitives around in the first place? They are not stored on disk anyway. The only reason I can think of is that it makes undo easier. But, for merging they should simply be ignored. Any objections to that? Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] self-intersecting ways
The Join Node to Way command currently inserts the node into all way segments within snap distance unless the node is already part of the way segment or the way segments are consecutive. This has the potential of producing self-intersecting ways by either joining a node to a way it is already member of or when a node is close to more than one non-consecutive way segments. The validator will put a warning on those ways. I am wondering whether JOSM should actively support the creation of self-intersecting ways or whether the Join Node to Way command should only join a node to ways it is not already member of. Also, I am wondering whether it should join a node only to the nearest way instead of all ways withing snap distance. If one wants to join the node to another way one can just repeat the command. Any opinions? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
Alan Mintz alan_mintz+...@earthlink.net writes: At 2010-02-23 09:41, Matthias Julius wrote: ... I am wondering whether JOSM should actively support the creation of self-intersecting ways or whether the Join Node to Way command should only join a node to ways it is not already member of. Based on my usage, the latter (do not join to existing parents of the node). Also, I am wondering whether it should join a node only to the nearest way instead of all ways withing snap distance. If one wants to join the node to another way one can just repeat the command. I like this. I'm often dealing with administrative boundaries that run down the centerlines of streets, and have to move either the boundary or the street to join a new cross-street. Of course, I'd really like to see the ability to ignore admin boundaries completely (perhaps during download), as they almost always are simply in the way, either because they have been glued to roads, or because they are close to roads. A similar problem exists with some landuse=* ways that people have glued to roads. IMHO the right thing to do for boundaries that run down the middle of roads, rivers, or other linear features to use those as members instead of duplicating the way. JOSM also has a hidden and undocumented filter feature with which it should be possible to hide objects you don't want to see. Of course this is hidden and undocumented for a reason. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Need special data extracts
Tim Teulings r...@edge.ping.de writes: Hello! (ah, another german :-)). I have not yet found a more convinient way than downloading a planet.osm You may want to query the XAPI for the relevant data http://wiki.openstreetmap.org/wiki/Xapi Unlike the main API which restricts queries to 0.25 square degrees, XAPI allows much larger requests, up to 100 square degrees So I could not get all capitals in one go but must call it multiple times... Not nice but doable. No, this restriction is only for the map API call where you specify a bounding box. With http://www.informationfreeway.org/api/0.6/*[...] you get all objects on the planet that match your criteria. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Matthias Julius li...@julius-net.net writes: Patrick Kilian o...@petschge.de writes: Hi, If you want to update the SVN directly that's fine with me too, in that case poke me when you have landed to code. I'll then update the tagstat instance on hypercube. Done, see r19945. I finally got around to update the tagstat instances for the planet and for haiti. It doesn't break anything obvious. In case there are any subtle bugs email me. Actually, I just made another small modification in r20068. This should prevent browsers (at least it does in FF) from displaying the response from the remotecontrol plugin. That saves the effort for going back to tagstat every time. I have just committed r20077. This adds the same links to tagpairs.php and tagvaluedetails.php. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Patrick Kilian o...@petschge.de writes: Hi, If you want to update the SVN directly that's fine with me too, in that case poke me when you have landed to code. I'll then update the tagstat instance on hypercube. Done, see r19945. I finally got around to update the tagstat instances for the planet and for haiti. It doesn't break anything obvious. In case there are any subtle bugs email me. Seems to work quite beautifully. Thanks, Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Patrick Kilian o...@petschge.de writes: Hi, If you want to update the SVN directly that's fine with me too, in that case poke me when you have landed to code. I'll then update the tagstat instance on hypercube. Done, see r19945. I finally got around to update the tagstat instances for the planet and for haiti. It doesn't break anything obvious. In case there are any subtle bugs email me. Actually, I just made another small modification in r20068. This should prevent browsers (at least it does in FF) from displaying the response from the remotecontrol plugin. That saves the effort for going back to tagstat every time. (Stolen from OSMdoc) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] deleting relations fails due to not fullfiled prerequirements
Sebastian Klein basti...@googlemail.com writes: Karl Guggisberg wrote: 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. I would say it is. Especially since it is not that straightforward to do when you have deleted both relations already in your local data. There is nothing wrong about deleting these two relations, why should it result in an error? We have already the rule to upload first all nodes, then all ways and then all relations. In a similar manner, JOSM should sort the relations in a way that keeps the server happy. Exactly, it could first delete relations that don't have referrers. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Next release end of February: status update
Karl Guggisberg karl.guggisb...@guggis.ch writes: 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*. As I wrote in the other thread I am not in favor of year based version numbers except for software that follows a strict yearly release schedule or where the year is somehow relevant (like tax software). For all others I prefer feature based version numbers where a change in the major part indicates substantial and potentially disruptive changes like a new API version or a completely new UI or so. Or, maybe a switch from Java to Perl. ;-) Matthias ___ 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
Frederik Ramm frede...@remote.org writes: Hi, Matthias Julius wrote: Exactly, it could first delete relations that don't have referrers. Be aware that circulare references are allowed. Yes, for these we need a two step process: 1. upload one of them with its members removed to break the circle 2. upload the deleted relations Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] use API v6 with Eclipse
kamélia BENCHEKROUN kamelia.benchekr...@gmail.com writes: I'm a student in a school engineering in France, and i have to develop a JAVA application connected to OpenstreetMap in order to get and edit information from the data base. I know that is possible with the API v 6 , but i don't know how to do it with Eclipse. How familiar are you with OSM? There are two major Java applications that come to my mind that deal with OSM data through the API: JOSM (http://josm.openstreetmap.de, source at http://josm.openstreetmap.de/svn/trunk) and Osmosis (http://wiki.openstreetmap.org/wiki/Osmosis, source at http://svn.openstreetmap.org/applications/utils/osmosis/trunk/) But, how to do Java development with Eclipse is a quite orthogonal issue and has nothing to do with what the application you are developing is doing. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] JOSM links in tagstat
Who is responsible for Tagstat? It would be helpful if tagstat would provide links to JOSM of the form http://localhost:8111/import?url=[url_to_xapi] next to the XAPI links. With the remotecontrol plugin JOSM then loads that URL automatically. This would eliminate a couple of steps when loading stuff into JOSM. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Patrick Petschge Kilian o...@petschge.de writes: Shouldn't be hard and sounds resonable enough. I'm quite busy at the moment so you either have to wait a week or two, or send me a patch relative to the source of tagstat. It can be found in SVN. Found it. Previously, I had only looked under /sites/ If you want to update the SVN directly that's fine with me too, in that case poke me when you have landed to code. I'll then update the tagstat instance on hypercube. Done, see r19945. Disclaimer: This is untested as I didn't feel like setting up tagwatch to be able to test it myself. I hope there is no escaping necessary. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Lars Francke lars.fran...@gmail.com writes: Disclaimer: This is untested as I didn't feel like setting up tagwatch to be able to test it myself. I hope there is no escaping necessary. Escaping is necessary[1]! Not escaping can cause problems for example with the | character as you might receive a lot more data than you expected[2]. I hope the XAPI URL is correct. The JOSM URL is using the same. I was more wondering about escaping for the browser to make sure it sends the right URL to JOSM. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Wireframe saves the day for a complex multipolygon
Marko Mäkelä marko.mak...@iki.fi writes: As long as the island is given some tags that identify it as an area, I believe that multipolygons have to be defined for the island-with-lakes. Why? You don't consider the lake on the island as part of the island? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Introduce versioning scheme
Karl Guggisberg karl.guggisb...@guggis.ch writes: Hi Sebastian Absolutely. That's one of the things we should do in the next release: * proper release naming * proper labeling in SVN I came up with a slightly different naming scheme, though. If we want to be understood by users with less technical background a release name 0.10.1-r1566 could be quite cryptic. I don't think the revision number needs to be part of the version number. Otherwise what is the point of sticking another number in front of it? We are not planning to make a release with every commit. The revision could be displayed in the About dialog. Also, I think a major and a minor version is enough. If it should really become necessary to fix a tested version we can stick a patch version number on it. For development I think it is best to stick with revision numbers. Why not simply call it 2010.01 (first release in 2010), 2010.02, etc. ? There won't be more than 4 releases a year anyway. I don't really see the need for a version number with three levels of increments. See for instance Ubuntu release numbering: https://help.ubuntu.com/6.10/ubuntu/about-ubuntu/C/version-numbers.html Personally, I don't like those year based version numbers. IMHO they only make sense if you follow a strictly yearly schedule. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Wireframe saves the day for a complex multipolygon
Frederik Ramm frede...@remote.org writes: Hi, Marko Mäkelä wrote: Btw. outer polygons are not used correctly in the lake, when there is small lake inside of island on the big lake, the small lake shouldn't be part of the big lake multipolygon. I followed the example on the wiki page http://wiki.openstreetmap.org/wiki/Relation:multipolygon which does suggest that lakes within islands can be defined as role=outer: I wrote that Wiki page and I still think it makes sense. This method (where there may be additional outers inside inners) also conforms to the OGC simple features geometry rules, i.e. everybody does it. This might be correct use of the Multipolygon relation, but is the lake on the island really part of the outer lake? If it is a separate lake with its own name I would say it should be a separate object for OSM. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] What's that new DownloadUrlAction?
Sebastian Klein basti...@googlemail.com writes: If you plan on writing a book sometime, you better check the first paragraph with google. :) I have no ambitions like that. Btw. the new 'duplicate layer' function seems useful, but maybe it suffices to put it in the right click menu of the layer. Hmmm, maybe, it certainly would be harder to find there. Other opinions? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] South Pole at 0,0 ?
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Tue, Jan 26, 2010 at 22:05, Matthias Julius li...@julius-net.net wrote: Mercator is defined right up to the poles - the scale just grows larger and larger and at the poles it is infinite. Our limit of about 85° comes from us wanting a square map. Would it be possible to switch to a different projection at some latitude? It certainly would be hard to seamlessly stitch it to the edges of our mercator map. Is anyone generating polar maps from OSM data? (I suspect there is not a whole lot of data.) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] South Pole at 0,0 ?
The Mapnik layer shows the South Pole at 0°, 0°. Unless my geography knowledge betrays me this is slightly off. There is nothing in the data in this location (after I deleted a couple of nodes there, but nothing that had anything to do with South Pole). I am wondering how Mapnik is dreaming that up. I have the suspicion that osm2pgsql (which is doing the conversation to Mercator, right?) somehow falls back to 0,0 when it can not deal with an indefinite northing value. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] South Pole at 0,0 ?
Martin Koppenhoefer dieterdre...@gmail.com writes: 2010/1/26 Matthias Julius li...@julius-net.net: I have the suspicion that osm2pgsql (which is doing the conversation to Mercator, right?) somehow falls back to 0,0 when it can not deal with an indefinite northing value. I also came across this issue, but AFAIK mercator is not suitable for north- and southpole: it is not defined in these regions (don't remember exactly but it was like bigger/smaller than 85 Deg. North/South). For further reading look for Mercator-projection in the Web. Of course, Mercator is not suitable for for the polar regions. The poles are in the infinite. That's why I would expect Mapnik not to put the South Pole on a Mercator map. And now look at our Mapnik layer: http://www.openstreetmap.org/?lat=0lon=0zoom=18layers=B000FTF Mercator is defined right up to the poles - the scale just grows larger and larger and at the poles it is infinite. Our limit of about 85° comes from us wanting a square map. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] location of elemstyles.xml and Eclipse
Pieren pier...@gmail.com writes: On Tue, Jan 26, 2010 at 7:11 AM, Matthias Julius li...@julius-net.netwrote: I think you have to add the /data in your eclipse project classpath (included path). Is it not already done in the commited .classpath ? /data is in there. But, elemstyles.xml is not in /data - it is copied to /build/data at build time. Of course, the obvious workaround is to copy the file manually into /data. But then I would have to remember to do that every time elemstyles.xml changes. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] location of elemstyles.xml and Eclipse
Since r2827 JOSM is loading elemstyles.xml from data/ and the file is copied there in build.xml Is there a way to have Eclipse do the same when JOSM is started from within Eclipse? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] location of elemstyles.xml and Eclipse
Ulf Lamping ulf.lamp...@googlemail.com writes: Am 25.01.2010 21:12, schrieb Matthias Julius: Since r2827 JOSM is loading elemstyles.xml from data/ and the file is copied there in build.xml Is there a way to have Eclipse do the same when JOSM is started from within Eclipse? You probably mean presets.xml vs. defaultpresets.xml? No, see http://josm.openstreetmap.de/changeset/2827/ In build.xml styles/standard/elemstyles.xml is copied to build/data and in MapPaintStyles.java the presets are loaded from resource://data/elemstyles.xml This works if you build JOSM by running ant, but eclipse does not care what is in build.xml What was actually wrong with loading elemstyles.xml from styles/standard/? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Ways containing same nodes
Anton Popov apo...@cloudmade.com writes: Thanks for you reply. I've asked about the creation possibility, because there were 2 ways and after some changeset has been commited, one way become overlapped by other. Ok, I will merge these ways using JOSM. You're too late. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways containing same nodes
Anton Popov apo...@cloudmade.com writes: Hello everybody, I've found two ways in Germany, that has same nodes: http://www.openstreetmap.org/browse/way/23735657 http://www.openstreetmap.org/browse/way/23735661 I've examined the history it seems that following changeset caused a problem: http://www.openstreetmap.org/browse/changeset/259367 The main questions are How this could happen? and How to correct these ways? There are many possibilities: A bug in the uploading software, the user somehow duplicating the way, the user not saving his data after uploading, or - most likely - an aborted HTTP connection after the server received the data (either by the user hitting cancel or by a broken network connection). The latter prevents the client from learning the IDs the server has assigned to new objects and on next upload it will re-upload the same objects again as new. As far as I can see correct way is 23735661 - the only missing tag is maxspeed - am I right? If the ways really have the same nodes one can do Combine Ways (C) in JOSM and JOSM will merge all tags onto one way. If they don't exactly overlap one can in JOSM select them both and all tags of both ways will be listed in the properties list with the tags that have different values displaying different. Then one can edit those tags and the values that are actually used by one of the selected ways are shown in bold in the value drop-down. Once all tag values are merged one can delete one way. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Localisation policy for quotes etc.
Dirk Stöcker openstreet...@dstoecker.de writes: On Wed, 13 Jan 2010, Matthias Julius wrote: I would like to delay all these issues until Launchpad has a proper fuzzy string handling (except these were texts are auto-fixed). Are those .po files downloadable somewhere? I can do the unfuzzying myself. The current state is always in OSM-SVN directory i18n. The ./launchpad.pl when called without URL updates all files and creates an upload-file for launchpad. When you change stuff, then you need first modify the po's and josm.pot and do update afterwards. When the strings are still there without fuzzy, then you did everything right. I have just checked in updated .po files as of JOSM r2875 into svn.osm.org Could you upload those to Launchpad? On a quick look I could not figure out where to upload the upload file to. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changes in presets ...
Ulf Lamping ulf.lamp...@googlemail.com writes: Hi! In the last two days I've compared the presets with map features, mappaint and current tag usage numbers. I've found several tiny things and some bigger issues missing (e.g. aeroway related stuff almost completely). After implementing the changes (together about 50 differences), I hesitate to check them in, as a new release is on the way - and stuff will need to be translated. Should I wait with the checkin after the release or will we going to handle the translations till then? If it is mostly new stuff I would not worry about translations. English presets are better than none. Also, since this will be the last Java 1.5 version I would aim for making is as complete as reasonably possible. This of course also includes the translations. Maybe we should give translators a couple more weeks after the new josm-tested is released. We could then update the translations in josm-tested. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localisation policy for quotes etc.
Dirk Stöcker openstreet...@dstoecker.de writes:
On Wed, 13 Jan 2010, Matthias Julius wrote:
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?
The correct way will be to escape single quotes with another one (''),
always.
In the near future all translations will be fed through
MessageFormat.format(), so they all get the same treatment.
Also, I want to change all those don'ts and won'ts to proper English.
This doesn't change the meaning of the string, so all the translations
(hopefully) just need to be unfuzzied.
There are a couple of other minor issues I came across that will get
fixed on the way.
I would like to delay all these issues until Launchpad has a proper fuzzy
string handling (except these were texts are auto-fixed).
Are those .po files downloadable somewhere? I can do the unfuzzying myself.
Matthias
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localisation policy for quotes etc.
Dirk Stöcker openstreet...@dstoecker.de writes: On Wed, 13 Jan 2010, Matthias Julius wrote: I would like to delay all these issues until Launchpad has a proper fuzzy string handling (except these were texts are auto-fixed). Are those .po files downloadable somewhere? I can do the unfuzzying myself. The current state is always in OSM-SVN directory i18n. The ./launchpad.pl when called without URL updates all files and creates an upload-file for launchpad. When you change stuff, then you need first modify the po's and josm.pot and do update afterwards. When the strings are still there without fuzzy, then you did everything right. I attached a script I used last time. I think I passed unchanged/changed strings pairs to it, but it was some time ago, I don't remember :-) OK, I will try that. BTW, I came across a number of strings where single quotes were not escaped. So I think this overhaul is a good thing. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localisation policy for quotes etc.
Marc Schütz schue...@gmx.net writes: Also, I want to change all those don'ts and won'ts to proper English. This doesn't change the meaning of the string, so all the translations (hopefully) just need to be unfuzzied. I thought, these don'ts and won'ts is proper english. Am I wrong? +1 Furthermore, don't and do not etc. are not freely interchangeable, as they have different connotations and for both there are situations where they are not appropriate. Well, this is true - especially for spoken language. This has probably much to do with the emphasis that is also put on it. There is certainly a difference between I won't do that. and I WILL NOT do that. But, in written language these shortcuts are consided casual and they are not used in formal texts, AFAIK. That's why I use this in emails, but not in the user interface of a program. Do we have any native English speakers here? It is somewhat silly to discuss subtle meanings of the English language between Germans. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localisation policy for quotes etc.
Karl Guggisberg karl.guggisb...@guggis.ch writes: I feel that the wording could be a little bit less formal in some cases. -- Karl Sure, I only fixed some real errors and some plural issues. Everybody is certainly welcome to make sugestions. 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. Well, while I was at it ... I didn't want to think about each instance whether or not it is maybe less important there. At least all the strings are consistent now. And, some of those were unescaped single quotes anyway. Now I just need to fix those po files ... Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localisation policy for quotes etc.
Andre Hinrichs andre.hinri...@gmx.de writes:
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?
The correct way will be to escape single quotes with another one (''),
always.
In the near future all translations will be fed through
MessageFormat.format(), so they all get the same treatment.
Also, I want to change all those don'ts and won'ts to proper English.
This doesn't change the meaning of the string, so all the translations
(hopefully) just need to be unfuzzied.
There are a couple of other minor issues I came across that will get
fixed on the way.
For translators it is probably best to take a break (and go mapping or
so) and wait for things to calm down. I guess Dirk should call a String
Freeze at some point.
Matthias
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] When are ways/relations in a changeset?
Andreas Kalsch andreaskal...@gmx.de writes: When I change the position of a node, will the way be in the changeset, too? When I change members of relations (without adding / removing members), will the relation be in the changeset, too? When you change a node only the node is uploaded to the API and therefore only the node is part of a changeset regardless whether it is used by a way or is a member of a relation. The same is true when you add an existing node to a way for example. Then, only the way itself is changed and not its nodes or relations it is a member of. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Localization of exception messages
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
Re: [josm-dev] Localization of exception messages
Dirk Stöcker openstreet...@dstoecker.de writes: Message intended to be visible to user must be translated. Messages meant as security checks or debugging texts which never should be visible to a user may remain untranslated. When in doubt they should be translated, but also descriptive for a user. Sure, if there is a chance a user gets to see the message it should be localized. But, there are many that have no meaning to the user whatsoever and that only get displayed by the unhandled exception dialog. To translate those only produces overhead for no benfit. I would actually argue that in most cases the exception handler needs to provide a meaningful message to the user because the method that throws it does not have the context to know what the user actually did or needs to do in order to solve the problem. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Major improvements to MapOSMatic
Lennard l...@xs4all.nl writes: Matthias Julius wrote: Are higher resolution icons an option? Probably, but you'll need lots of different sizes for different sized areas. Really? The level of detail one wants to see is independent of the size of the area. If I want to print a 1:1 map all icons are going to be the same size. The size on the PDF is fixed anyway. The parking icon I have just looked at seems to be 16x16 pixels and because the strokes are not aligned to pixels it looks pretty blurry when one zooms to a level where they are about 5 mm tall due to anti-aliasing. It would look a lot better if they had 32x32 or even more pixels. The size on the PDF should not change, of course. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
Thomas Petazzoni thomas.petazz...@enix.org writes: As a new year's present, the MapOSMatic team is proud to announce that a new version of the maposmatic.org website has been put online, with major improvements over the initial version announced in September 2009. I like it! I have one request: The PDFs are very nice vector graphics - except for the icons. When zooming in to detail level they look ugly. Could they be included as vectors, too? (Aren't they derived from SVGs?) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Frederik Ramm frede...@remote.org writes: Hi, Greg Oseid wrote: Are there other stylesheets available besides the osm.xml file that is included with Mapnik? I think there's a lot of people who have made their own style sheets and who would be willing to share, it's just that we have not agreed on a standard way. We should really have some kind of platform where people can upload their styles and others can build their own variants. Could the OSM wiki be used for that, or would it be a case for put stylesheet in SVN and make an illustrated Wiki page documenting it? One problem with mapnik stylesheets is that they are a chore to work with. Anyone up to implementing a (graphical) stylesheet generator? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Ulf Lamping ulf.lamp...@googlemail.com writes: Am 23.12.2009 23:14, schrieb Matthias Julius: Frederik Rammfrede...@remote.org writes: Hi, Greg Oseid wrote: Are there other stylesheets available besides the osm.xml file that is included with Mapnik? I think there's a lot of people who have made their own style sheets and who would be willing to share, it's just that we have not agreed on a standard way. We should really have some kind of platform where people can upload their styles and others can build their own variants. Could the OSM wiki be used for that, or would it be a case for put stylesheet in SVN and make an illustrated Wiki page documenting it? One problem with mapnik stylesheets is that they are a chore to work with. Anyone up to implementing a (graphical) stylesheet generator? To be able to write a stylesheet generator, it will be extremely helpful to have more than one stylesheet example to get an idea of what people are actually doing with the stylesheets :-) Do you need example texts to be able to write a text editor? ;-) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Shaun McDonald sh...@shaunmcdonald.me.uk writes: On 23 Dec 2009, at 22:14, Matthias Julius wrote: One problem with mapnik stylesheets is that they are a chore to work with. Anyone up to implementing a (graphical) stylesheet generator? That's effectively what the CloudMade style editor does, just you can't access the style sheet and host it yourself. Isn't that then a small step to offer a download option for the generated stylesheet? Of course, this is only useful if one uses CM's database schema. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Reversing of node tags
I am currently pondering about http://josm.openstreetmap.de/ticket/4149 (JOSM is producing an exception when the reversal of a way that included reversing of a tag is undone. This is because the tag correction is done on a intermediate way which does not belong to a dataset and when undoing this JOSM tries to look up the nodes from the node ids in the WayData.) While looking a the code I noticed that JOSM is looking at all the way nodes for reversible tags. Does it even make sense to have nodes with direction dependent tags? I doubt that. This is ambiguous when more than one way uses that node (and JOSM does not check for this when reversing the tags). If there are no objections I will remove that from the code. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Reversing of node tags
Alan Mintz alan_mintz+...@earthlink.net writes: While you're at it, if it's simple, it would be nice if it did not bring up the Automatic tag correction dialog if there is no difference between any of the new value and old value fields. This is common in the case of reversing a way that is not oneway, where the tiger:zip_left and tiger_zip:right values are the same. I'll see what I can do. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Reversing of node tags
Frederik Ramm frede...@remote.org writes: Hm. There is for example highway=incline and highway=incline_steep, used more than 1600 times nodes in Germany alone. They usually come in tandem with incline=xx% which would have to be turned into incline=-xx% when the way is reversed. I would consider those tags on nodes as broken. These should all be way tags. I would propose to change Map Features in this respect and have the JOSM Validator, Maplint Co. put warnings on nodes where they exist. An incline that fits into a node is either so low that it is not worth tagging at all or is so steep that it should better be tagged as cliff. ;-) Actually highway=incline[_steep] should be discouraged alltogether. http://wiki.openstreetmap.org/wiki/Key:incline mentions incline=up and incline=down for cases when the exact value is not known. Also, inline=* can be used for other things beside highways. You are right in saying that this is ambiguous in theory. In practice, of roughly 1650 occurrences in Germany, 1441 were used by only one way; 167 were used by two ways (every case I checked was simply where one way ended and another began), and 34 were used by more than 2 ways (the most adventurous one being http://www.openstreetmap.org/browse/node/302422098 but this looks like someone has misunderstood something). The remaining ones were not used by any way. Even in the case where the node simply connects two ways there is a problem if one of them gets reversed. I don't even known if JOSM handles this correctly at the moment, but if it does then it should perhaps not be broken? JOSM currently looks for left/right, forward/backward, forwards/backwards and oneway tags, values and relation roles. There is no reversal for highway=incline. All JOSM could do is put out a warning. It certainly makes sense to include incline=* - most of which are on ways anyway (according to OSMdoc). Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Can't commit any more - SVN issue?
Dirk Stöcker openstreet...@dstoecker.de writes: On Mon, 21 Dec 2009, Karl Guggisberg wrote: Could somebody with access to the server please have a look? The server has load problems. This should be temporary, so please retry. It just worked for me. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
Paul Johnson ba...@ursamundi.org writes: Tobias Wendorff wrote: Matthew W. S. Bell schrieb: I think the key point here that the projection used for geometry editing should be a conformal[1] one (i.e., angle preserving) like those in [2]. Possibly, the projection should have an even greater restriction. Conformal for what distance? It's easy to do some accurate calculations up to 1 km, but 10 km or even 100 is much more difficult, BUT: who draws such big rectangles and circels in OSM? Say you want to draw Whyoming... This is actually a good example why we might want to use Mercator for calculating rectangles. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
Anthony o...@inbox.org writes: On Thu, Dec 17, 2009 at 7:32 PM, Matthias Julius li...@julius-net.netwrote: My point was that Wyoming *is* a rectangle in a Mercator projection. Well, it would have been if they had surveyed it correctly: http://www.openstreetmap.org/?lat=44.996lon=-110.625zoom=11layers=B000FTF Yes, I know. Wikipedia also mentions that the border is actually up to half a mile off. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Structured error messages from API
Karl Guggisberg karl.guggisb...@guggis.ch writes: For JOSM, the structured data currently embedded in the error message is important. Examples are object ids of already deleted objects (410 Gone) or a date (the close date of a changeset in a 409 Conflict). I'd prefer a parseable error document in case of http error codes, preferably in XML. This would not be much of a change because the content of the 'Error' http header is already replied as error document too (sometimes for some error cases). It would be nice if the OSM API replied a message in english *and* and in the language supplied in the Accept-Language http header. Example: osm-api-error error-id code=1232 / !-- unique error code? would be nice too -- message lang=enUpload of an object failed./message message lang=deHochladen eines Objekts ist fehlgeschlagen./message property name=object-id value=1223/ property name=closed-date value=/ /osm-api-error XML is probably the best solution because it is flexible and anybody communicating with the API knows how to pars XML anyway. Any objections against changing the body of the error document from the current text string (which is a duplicate of the Error header, AFAICT) to a XML document? Anybody interested in helping to come up with a specification for this? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Richard Fairhurst rich...@systemed.net writes: Tom Hughes wrote: Basically, even if sending a streaming response from rails was possible (which I'm not sure it is - it's certainly hard) You can do it using render :text=proc, as amf_controller does. But I suspect this would be non-trivial to work into the existing XML API. The API could also return an URL which the client can poll to get the status for an upload. This would also avoid issues with client timeouts. Currently, when the client hits a timeout and aborts the connection it has no way of knowing whether the upload succeeded or not. For new data this creates duplicates when the user tries to upload again. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Patches in trac
I would be grateful if someone would have some pity with some of the patches that are lingering in trac. Especially the one in http://josm.openstreetmap.de/ticket/4146 is quite important since it fixes a really annoying issue (ways with incomplete nodes). Of course, if there is anything wrong with them I would be happy about some feedback. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Patches in trac
Dirk Stöcker openstreet...@dstoecker.de writes: On Fri, 11 Dec 2009, Matthias Julius wrote: I would be grateful if someone would have some pity with some of the patches that are lingering in trac. Especially the one in http://josm.openstreetmap.de/ticket/4146 is quite important since it fixes a really annoying issue (ways with incomplete nodes). Of course, if there is anything wrong with them I would be happy about some feedback. Don't forget this is OpenSource. Sometimes we simply don't have free time for that (which usually means stuff is delayed until weekend). But you're on a good way to get your own account, so be patient a little while longer and continue to make good quality patches :-) OK, I'll try. Most of them are not so urgent, but, the one mentioned above is. It makes josm-latest really buggy. Having ways with incomplete nodes is not only ugly, it is causing all kinds of issue because there are many places where this is not expected. One could argue, of course, that these are all bugs. Anyway i would really like to see #4146 fixed before the next nightly build. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Structured error messages from API
Karl Guggisberg karl.guggisb...@guggis.ch writes: Anybody interested in helping to come up with a specification for this? I am. How can I help? Hmmm, where to start? I guess we first need to make a list of things we want to be included in the error document. If I find the time tonight, I will start browsing the rails code for all the API errors it might emit. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Structured error messages from API
There are requests in JOSM's trac to improve the handling of API errors. To do that JOSM needs to get a better understanding on what is wrong with the data. Currently, JOSM is parsing the error strings the API is returning. This is far from ideal because they are not structured, not documented and might change without warning. To improve things I would like to see the API extended to return meta data about errors (error type, id of offending element, ...) in a structured way. There are a couple of ways to that (that came to my mind): - change the Error header - add home-made HTTP headers (X-Error-Type ...) - add pseudo headers to the body - return a XML document containing all the info (see also http://trac.openstreetmap.org/ticket/2544) What do you think? How important is that to people on the receiving end (application developers)? Any suggestions how the format should be? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] restart JOSM
Dirk Stöcker openstreet...@dstoecker.de writes: On Thu, 10 Dec 2009, Dieter Muecke wrote: Instead of restarting JOSM by hand after plugin update the code snippet below does it programmatically. It works on Mac OSX but before I submit a patch I would like know how do the same on Windows and Linux. Why do you want restarting JOSM after plugin update? The plugin update on startup is done before loading the plugins, so already the new plugins are loaded. And in any other case programmatically restarting is a bad idea as well (webstart, applet, security issues, ...). Plus, unless the current state (loaded data, zoom etc.) survives the restart the benefit for the user is negligible. In my view that's not worth jumping through hoops to make it work on all platforms. Better would be if there was a way to reload plugins without having to restart JOSM. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
