[Potlatch-dev] [OpenStreetMap] #4478: Relation properties dialog is too small
#4478: Relation properties dialog is too small ---+ Reporter: knockknockpenny@… | Owner: potlatch-dev@… Type: defect | Status: new Priority: major | Milestone: Component: potlatch2 | Version: Keywords: relation, UI | ---+ When I open relation properties in Potlatch 2: https://www.dropbox.com/s/yzsp70gu0tl17mo/potlatch2-screenshot-1.png As you can see advanced properties and members are not visible. I need to scroll to access it: https://www.dropbox.com/s/0wa7ltlzm5alqzv/potlatch2-screenshot-2.png Also relation properties dialog is not resizeable. It's realy annoying. == Minimal patch == file: RelationEditorPanel.mxml -- title=Edit Relation width=350 height=400 ++ title=Edit Relation width=450 height=500 -- Ticket URL: https://trac.openstreetmap.org/ticket/4478 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Attribution string (was: Licence redaction ready to begin)
Why not use TileJSON? http://mapbox.com/developers/tilejson/ Igor On Thu, Jul 12, 2012 at 7:12 AM, Kai Krueger kakrue...@gmail.com wrote: On 07/10/2012 01:38 PM, Lynn W. Deffenbaugh (Mr) wrote: I've been wondering if it would be possible to put a fixed URL on the tile and/or API servers that application programs could fetch to retrieve the current attribution string for that particular tile server? Something like 0/0/0.txt or some-such that we could simply code into the tile-based clients to fetch the desired string instead of coding it directly in the clients? I think this sounds like a good idea. Rather than 0/0/0.txt, I would use a name like attribution.txt or license.txt in the base directory of the tile style. It allows for different attribution for different styles on the same server while still having a meaningful name. In addition I would suggest to add an attribution.html that has the attribution string as a html snippet with the correct hyperlink to the license and contributors. If people think this is useful, I could add this to mod_tile to help standardize the attribution URL. Kai Since we all have to go in and change the attribution anyway, now might be a really good time to make it a fetchable string. Lynn (D) - KJ4ERJ PS. I'm proposing a plain text string that can then be integrated into a client display here. Another fixed URL per tile server could provide the reference URL string so that said applications can make the text attribution a link going there. On 7/10/2012 3:32 PM, Michael Collinson wrote: Hi Paul, We discussed this tonight at LWG https://docs.google.com/document/pub?id=1W7eh17a7cEUilpbictKYnWJfHoxIcA1W_tPEmqvmDkcitem 5 We do not think temporary dual-licensing is particularly practical or necessary provided that we allow consumers reasonable time to make their attribution string changes. We are happy to re-visit this if there is any strong reason we are not seeing. Mike LWG * From: Richard Fairhurst [mailto:richard at systemeD.net http://lists.openstreetmap.org/listinfo/dev]** Subject: [OSM-dev] Licence redaction ready to begin** ** Once it is complete, we will be ready to distribute data under the ODbL** and we'll advise of that with a separate announcement. The final pre-** redaction dataset available under CC-BY-SA has now been generated at** http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has** been redacted, any attempt to access it from the API or the site's** 'browse' pages will return a response to that effect.* To transition from tiles derived from a CC BY-SA source to tiles derived from a ODbL source will require changing the attribution and regenerating all tiles so that CC BY-SA data is not mis-represented as being ODbL data. What time period will data be available under dual licenses so that tile servers will not have to reload their database then immediately delete every cached tile when changing their attribution? When I discussed this with Frederik awhile back I suggested publishing the first post-redaction planet as dual-licensed as well as one week of diffs to allow tile servers to continue to serve old CC BY-SA tiles and re-render over the course of a week. At the very least I would suggest distributing the first post-redaction planet as dual-licensed for the simple reason that all the information to create it will be available as CC BY-SA. ___ dev mailing listdev@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Attribution string (was: Licence redaction ready to begin)
On Thu, Jul 12, 2012 at 08:45:38AM +0200, Igor Brejc wrote: Date: Thu, 12 Jul 2012 08:45:38 +0200 From: Igor Brejc igor.br...@gmail.com To: Kai Krueger kakrue...@gmail.com Cc: dev@openstreetmap.org dev@openstreetmap.org Subject: Re: [OSM-dev] Attribution string (was: Licence redaction ready to begin) Why not use TileJSON? http://mapbox.com/developers/tilejson/ +1 I hadn't known about this before but just looked at it and it seems to be a well thought-out and documented standard. Igor On Thu, Jul 12, 2012 at 7:12 AM, Kai Krueger kakrue...@gmail.com wrote: On 07/10/2012 01:38 PM, Lynn W. Deffenbaugh (Mr) wrote: I've been wondering if it would be possible to put a fixed URL on the tile and/or API servers that application programs could fetch to retrieve the current attribution string for that particular tile server? Something like 0/0/0.txt or some-such that we could simply code into the tile-based clients to fetch the desired string instead of coding it directly in the clients? I think this sounds like a good idea. Rather than 0/0/0.txt, I would use a name like attribution.txt or license.txt in the base directory of the tile style. It allows for different attribution for different styles on the same server while still having a meaningful name. In addition I would suggest to add an attribution.html that has the attribution string as a html snippet with the correct hyperlink to the license and contributors. If people think this is useful, I could add this to mod_tile to help standardize the attribution URL. Kai Since we all have to go in and change the attribution anyway, now might be a really good time to make it a fetchable string. Lynn (D) - KJ4ERJ PS. I'm proposing a plain text string that can then be integrated into a client display here. Another fixed URL per tile server could provide the reference URL string so that said applications can make the text attribution a link going there. On 7/10/2012 3:32 PM, Michael Collinson wrote: Hi Paul, We discussed this tonight at LWG https://docs.google.com/document/pub?id=1W7eh17a7cEUilpbictKYnWJfHoxIcA1W_tPEmqvmDkcitem 5 We do not think temporary dual-licensing is particularly practical or necessary provided that we allow consumers reasonable time to make their attribution string changes. We are happy to re-visit this if there is any strong reason we are not seeing. Mike LWG * From: Richard Fairhurst [mailto:richard at systemeD.net http://lists.openstreetmap.org/listinfo/dev]** Subject: [OSM-dev] Licence redaction ready to begin** ** Once it is complete, we will be ready to distribute data under the ODbL** and we'll advise of that with a separate announcement. The final pre-** redaction dataset available under CC-BY-SA has now been generated at** http://planet.openstreetmap.org/planet-120704.osm.bz2 . Where data has** been redacted, any attempt to access it from the API or the site's** 'browse' pages will return a response to that effect.* To transition from tiles derived from a CC BY-SA source to tiles derived from a ODbL source will require changing the attribution and regenerating all tiles so that CC BY-SA data is not mis-represented as being ODbL data. What time period will data be available under dual licenses so that tile servers will not have to reload their database then immediately delete every cached tile when changing their attribution? When I discussed this with Frederik awhile back I suggested publishing the first post-redaction planet as dual-licensed as well as one week of diffs to allow tile servers to continue to serve old CC BY-SA tiles and re-render over the course of a week. At the very least I would suggest distributing the first post-redaction planet as dual-licensed for the simple reason that all the information to create it will be available as CC BY-SA. ___ dev mailing listdev@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API change
On Thu, Jul 12, 2012 at 08:55:09AM +0200, Frederik Ramm wrote: On 07/11/12 22:51, Richard Fairhurst wrote: In an ideal world we would like to have given more warning. But as a former JOSM maintainer has proudly proclaimed beforehand Software whose programmers whine about having to make a change deserves to die, or be banned, then I have no doubt that JOSM will, as ever, rise to the challenge. It's high time that JOSM starts to play in Potlatch's league. Let's remove 90% of the features ;) I think this discussion needs to be escalated to a higher level: http://twitpic.com/7pwgld I am glad you two are having fun... But is this change documented somewhere now? Are there test cases I could test my software against? There are a few more programs reading those XML files, you know... Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API change
Hi, On 07/12/12 09:15, Jochen Topf wrote: But is this change documented somewhere now? I think all we currently have to offer is this: http://git.openstreetmap.org/rails.git/commit/2c67c079ac39cefd3b096524fc0b7364b0eb21d7 Of course anyone is welcome to fix any API documentation they might find accordingly! Are there test cases I could test my software against? As for test cases, downloading the XML for *any* deleted node will show the changed XML; if you want to look at what the bot does specifically, pick one of these changesets: http://www.openstreetmap.org/user/OSMF%20Redaction%20Account/edits There are a few more programs reading those XML files, you know... There haven't been any changes to *file* formats yet, just transfer formats; the planet file doesn't have deleted nodes, and the history planet export script hasn't been modified yet (but will probably be in due course). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API change
On Thu, Jul 12, 2012 at 09:23:59AM +0200, Frederik Ramm wrote: There are a few more programs reading those XML files, you know... There haven't been any changes to *file* formats yet, just transfer formats; the planet file doesn't have deleted nodes, and the history planet export script hasn't been modified yet (but will probably be in due course). There never was a difference between what you call file formats and transfer formats. Software that could read one could read the other. In all cases it is just the XML representation of OSM data. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Attribution string
On 7/12/2012 1:12 AM, Kai Krueger wrote: On 07/10/2012 01:38 PM, Lynn W. Deffenbaugh (Mr) wrote: I've been wondering if it would be possible to put a fixed URL on the tile and/or API servers that application programs could fetch to retrieve the current attribution string for that particular tile server? Something like 0/0/0.txt or some-such that we could simply code into the tile-based clients to fetch the desired string instead of coding it directly in the clients? I think this sounds like a good idea. Rather than 0/0/0.txt, I would use a name like attribution.txt or license.txt in the base directory of the tile style. It allows for different attribution for different styles on the same server while still having a meaningful name. In addition I would suggest to add an attribution.html that has the attribution string as a html snippet with the correct hyperlink to the license and contributors. If people think this is useful, I could add this to mod_tile to help standardize the attribution URL. You captured my request precisely and I like your proposed names as well. And for anyone looking to balance this off against precedent, just think of robots.txt, but at the base directory of each tile style. This would go a long way to making attribution a) easier, b) under the control of the style publisher, and c) possible to be displayed by tile clients that allow user-configuration of the tile servers. Right now, my software can't really tell whose tiles are being displayed in order to provide correct attribution because the user configures the tile server, port, and URL prototype. Lynn (D) - KJ4ERJ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Attribution string
On 7/12/2012 3:10 AM, Jochen Topf wrote: On Thu, Jul 12, 2012 at 08:45:38AM +0200, Igor Brejc wrote: Date: Thu, 12 Jul 2012 08:45:38 +0200 From: Igor Brejc igor.br...@gmail.com To: Kai Krueger kakrue...@gmail.com Cc: dev@openstreetmap.org dev@openstreetmap.org Subject: Re: [OSM-dev] Attribution string (was: Licence redaction ready to begin) Why not use TileJSON? http://mapbox.com/developers/tilejson/ +1 I hadn't known about this before but just looked at it and it seems to be a well thought-out and documented standard. Agreed, but I'm still looking for a plain text attribution in addition to a URL to refer to. Their description of attribution is apparently plain text, but their example attribution contains HTML. Seems it should have an attribution text and attribution link so as to remove the ambiguity as to use. Lynn (D) - KJ4ERJ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Exhaustion of 32bit signed integer range expected this year
On Wed, 11 Jul 2012 22:32:30 -0700 (PDT) Kai Krueger kakrue...@gmail.com wrote: SimonPoole wrote It seems as if it would really make sense to make the 64bit ID version of osm2pgsql the default now and communicate that it might be a good idea to switch on the upcoming reload. So I'll bring this topic up again: Should the default of osm2pgsql be changed to the 64 bit ID version now? absolutely!!! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Update on redaction bot and minutely diffs
As I mentioned yesterday, the bot caused some problems with minutely diffs. Andy just sent a more detailed message about the technical problems to the rebuild list but here is a quick update for the user side of things. Some invalid diffs were generated yesterday. These have been removed from planet.osm.org and replaced this morning with valid files after a workaround was put into osmosis. This means that if you have a setup that is consuming minutely diffs, you may need to manually intervene. According to Grant, the last valid diff was: http://planet.openstreetmap.org/redaction-period/minute-replicate/000/141/272.osc.gz So you will want to stop osmosis and replace its state.txt file with the contents of: http://planet.openstreetmap.org/redaction-period/minute-replicate/000/141/272.state.txt And then restart your minutely update process. The first 20 or so diffs are substantially larger than normal so it may take a while to catch up. As for the bot itself, it was stopped after a few hours yesterday because some problems were discovered with its handling of relation members. Again, see the rebuild list for details. The short version is that he fixed it and as of a few minutes ago the bot is running again. There was also a problem caused in JOSM which might affect you if you are working in an area with other people. If someone else deletes a node and then you try to update it, JOSM had problems dealing with the deleted node because of a slight change in the API. This has already been fixed according to this trac ticket: http://josm.openstreetmap.de/ticket/7847 So I think we've had our glitches. It'll be smooth sailing from here on, right? :) Toby ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi Jan, This is looking very good - much more intuitive than the original interface where you had to press the menu key, and nice easy access to the upload/download feature, which gets used a lot. A couple of comments that I think would improve it more: - It is not obvious to me that the little triangle in the menu bar means that it is a drop down menu - the triangle is a long way away from the 'Move' text etc., which makes it look like a separate icon rather than being linked to that text. - Do we have to have a separate 'Edit' and 'Edit Tags' mode? I spent a little while with it in 'Edit' mode wondering why clicking on a way did not bring up a tag editing dialog - would it be possible to make a long click bring up the tag editor, and a short drag move the node? - Actually, now I wonder what the 'move' mode is now - we seem to have three modes that are about editing existing entities - Move, Edit and Edit Tags - simplifying this would really help. Regards Graham. On 7 July 2012 09:50, Jan Schejbal jan.mailinglis...@googlemail.com wrote: Am 2012-06-18 07:23, schrieb Jan Schejbal: The API with all changes so far can be downloaded at http://www.janschejbal.de/temp/vespucci.apk Sorry, I only managed to fix some small bugs in the last weeks (Repo and APK is updated). I have exams on the 10th and 11th that take more time than expected to learn for. I think that the primary features are implemented, but not yet thoroughly tested or debugged, and will still need some improvements (e.g. auto-suggest tag names/values based on presets). Feedback on the existing functionality would be appreciated. Kind regards Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-12 22:43, schrieb Graham Jones: Hi Jan, This is looking very good - much more intuitive than the original interface where you had to press the menu key, and nice easy access to the upload/download feature, which gets used a lot. Thanks! A couple of comments that I think would improve it more: - It is not obvious to me that the little triangle in the menu bar means that it is a drop down menu - the triangle is a long way away from the 'Move' text etc., which makes it look like a separate icon rather than being linked to that text. This is a default thing caused by using the ActionBar interface. I am working on a workaround, but it seems quite difficult. I have an ugly hack, but am looking for a clean solution. I'll either try to create a separate background color for the dropdown, or at least right-aligning the view. - Do we have to have a separate 'Edit' and 'Edit Tags' mode? I spent a little while with it in 'Edit' mode wondering why clicking on a way did not bring up a tag editing dialog - would it be possible to make a long click bring up the tag editor, and a short drag move the node? This corresponds to the original modes that were present before I started with my project. The EasyEdit mode which I created provides such a combined mode as you suggest: tap-and-drag moves a node, double-tap opens the tag editor. The first tap is needed as otherwise it would be nearly impossible to scroll the map in densely-populated areas as soon as you zoom out (every pixel is in the edit radius of a node then). I would suggest to either keep the edit/edit tags modes as they are (for users who want to tag/move without the additional tap) or just remove them. - Actually, now I wonder what the 'move' mode is now - we seem to have three modes that are about editing existing entities - Move, Edit and Edit Tags - simplifying this would really help. I think move means move/scroll the map view without changing anything. We could rename this to read-only or something similar. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Validator
On Wed, 11 Jul 2012, Frederik Ramm wrote: The idea behind this is that users actually fix these issues. When we no longer display them, then they wont get fixed at all. The system has already been tuned a lot, Exactly. This is what the newbie will think as well: The system has been tuned a lot, this editor is used by thousands of mappers every day, so it MUST BE RIGHT and I am responsible for all these bugs! Oh dear! I believe you mix newbie and dumb person here. Newbie does not mean a brainless person, but only one who does not know OSM very well. But he can read dialogs and also understand them. If not, then probably JOSM is not the right tool for him anyway. so that the warnings and errors have few false positives and information level is disabled in default. We're not talking about false positives. We're talking about things that are indeed problems that need to be fixed, but we're showing them to the wrong person - someone who lacks the necessary time or first-hand information to fix them. Then I agree with Pierre, that we probably need additional help (e.g. wiki pages) describing each error and warning and how to fix it. As always help is welcome. The related pages http://josm.openstreetmap.de/wiki/Help/Preferences/Validator and http://josm.openstreetmap.de/wiki/Help/Dialog/Validator and http://josm.openstreetmap.de/wiki/Help/HowTo/ValidatorExamples and http://josm.openstreetmap.de/wiki/Help/Action/Validate (missing) need a lot of updating. As programmer I say an error is an error and it makes no sense to divide it into my error and your error. Oh yes it does. Because if you have made a change that *causes* a problem, and then a message discourages you from uploading at all, then that's not too bad. But if you make a change that just happens to lead to *unrelated* problems being highlighted, and you then decide to rather not upload your change, then this is a loss for OSM. If a change causes a problem, then the text tells you to upload anyway. And later probably ask someone else to check if it is ok. My father doing much more mapping than myself from time to time gets such requests to verify and/or fix complex situations always helping the people to do it themselves the next time. Problem with errors usually is not the error itself, but the harsh tone in OSM when someone made an error. But this is nothing which software can change. And a beginner getting tons of errors also touched tons of objects which probably is no good idea at all when you don't know what you do... Is it not possible to touch one large object which has e.g. 20 level crossings with other ways and then get 20 warnings just because you added a tag to that one big thing? At least that's what the guy on talk-us claimed. Sure it is. And then for US you google (j)osm crossing ways warning and find a short help how to proceed in the first link. For other languages it is more complicated to find proper help. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
On Wed, 11 Jul 2012, Pierre Béland wrote: This over verification may become counterproductive since contributors may have the reaction to always ignore validation messages. People tend to ignore warning dialogs in every type of software. JOSM probably is no big exception to this. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
Is it possible to make an option for the validator so that you can choose between validating only touched objects and all objects? Then put it default on only touched objects for new installations so that newbies only see the errors on objects they actually touched. Regards, Maarten ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
On Thu, Jul 12, 2012 at 1:44 AM, Maarten Deen md...@xs4all.nl wrote: Is it possible to make an option for the validator so that you can choose between validating only touched objects and all objects? Then put it default on only touched objects for new installations so that newbies only see the errors on objects they actually touched. Like I said, this is already the default behavior on upload. To validate everything you have to actually click the validate button manually. Toby ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
From: Maarten Deen [mailto:md...@xs4all.nl] Subject: Re: [josm-dev] Validator Is it possible to make an option for the validator so that you can choose between validating only touched objects and all objects? Then put it default on only touched objects for new installations so that newbies only see the errors on objects they actually touched. By default on upload it only checks touched objects. This still reports errors that already existed and the user did not create. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/07/12 08:36, Dirk Stöcker wrote: On Wed, 11 Jul 2012, Pierre Béland wrote: This over verification may become counterproductive since contributors may have the reaction to always ignore validation messages. People tend to ignore warning dialogs in every type of software. JOSM probably is no big exception to this. Exactly. I did fix a lot of errors and warnings on one island of the Acores last week. The errors where all made by newbees with JOSM (pt) and mostly new objects. I do not know if there are big differences between the languages (en,de - pt), but I doubt that this was the reason for unconnected node, doubled nodes, unconnected roads and crossing roads without common node or layer tag. There is definitly room for improvements in layout and links to howto to fix within the dialogue but right know I hope that a user who is confused will rather ask some others for help than simply ignoring the dialogue or throwing away his/her changes. Cheers colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAk/+3uYACgkQalWTFLzqsCsevQCgmG96vGnXV87kIBf086Yx5pqJ S/YAn1TJRxK/zdmOlHUwwDBHPegesSbm =NhaB -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] New tested version after API change fix?
Hi, In the process of the license switch, there has been a small change of the OSM API [1]. This causes JOSM to crash in certain situations [2][3]. A fix has been committed (v. 5326), so as a user you might want to update JOSM or at least save often, especially before upload and data update. @team: Do you think we should release an emergency tested version? The fix [5326] might cause a couple of bugs at other places, so in any case no need to rush things. [1] http://lists.openstreetmap.org/pipermail/dev/2012-July/025209.html [2] http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000317.html [3] http://josm.openstreetmap.de/ticket/7847 Paul ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
2012/7/11 Frederik Ramm frede...@remote.org: Do you think it would be possible to run the validator after data has been downloaded and record the list of problems, and then when someone uploads, only check for *newly added* problems instead of everything? Of course the validator would still, on request, be able to check everything, but the automatic hey, are you sure you want to upload this check could be reduced to those problems this mapper is really responsible for, rather than listing everything that was wrong even before this mapper touched it. If the user can highlight the validation errors that are directly caused by the local modifications, this is certainly an improvement. But I'm not so sure about the technical implementation. It doesn't seem natural to me to validate the entire dataset on download and keep the errors till some of theses objects are (maybe) uploaded. What if the edits are saved to a .osm file and reloaded later? I'd suggest an alternative: Remember the original version of each primitive; on upload run 2 passes for the validator: one for the (reconstructed) original dataset and one for the modified one. This solution isn't necessarily easier to implement, but it solves other problems as well: Currently, if you add a tag to a large number of objects, and later remove that tag, JOSM still keeps the modified flag for these objects, so they get uploaded and get a version bump, although the properties remain unchanged. In addition it would be useful to display the changes made to an object before upload (e.g. for a large relation; much like svn status). The history GUI could be reused for this. This still requires an extension of the data file format used in JOSM, but I think it's inevitable. There are a couple of other things that need to be saved to file, e.g. object histories and edit conflicts. The plain .osm format can be offered as export option instead. Paul ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
