Re: [OSM-dev] Improving History and Monitoring
On 7 May 2011 16:18, Tom Hughes t...@compton.nu wrote: I don't see the point of distinguishing big edits because people don't really care - the only thing they really case about is whether the edit touches a given area. Big is simply a (poor) proxy for that. You've touched on something here that I've been thinking about. One way of restating our goal in highlighting certain changes, either in the overall history or in the changesets of an individual mapper, is: It would be nice to see highlighted, or be able to filter based on, changesets that are interesting to you. If we can once define one or more definition of interesting it would be possible to flag or filter accordingly. Some possible definitions of interesting: * Is within a certain radius of a certain location, very likely the current user's set home location. To support this, a user profile would allow setting of the radius of interest according to how much that mapper gets around. * Is within a certain radius (and this might be a fixed distance for all mappers) of something the current mapper mapped. * Is inside a certain bbox which the mapper would get to define in his profile. A bit like the radius mentioned above, but maybe more useful. In this context a big edit might still be interesting - but not if it simply encompasses an area of interest. It would probably have to include edits that were themselves inside the area of interest. That seems hard, though. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] License change plugin
On 6 May 2011 22:55, Frederik Ramm frede...@remote.org wrote: I have just committed a first alpha of a license change plugin (svn.openstreetmap.org/applications/editors/josm/plugins/licensechange). Great! This is a tool I've wanted for quite a while. It seems to be doing what it's supposed to, but with an interesting quirk that's probably not a plugin issue at all, but rather one related to your history web service. Consider this node: http://www.openstreetmap.org/browse/node/256435531/history Conveniently for test purposes, it is still at version 1, and the creating mapper has (though only recently) accepted the CT. So given that the status of data will be changing fairly swiftly, how long should we expect it to take before the history service notices a new acceptance? Thanks, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Paging the tile server admins
On 27 April 2011 14:08, Jaak Laineste jaak.laine...@gmail.com wrote: Good application = a) is www.openstreetmap.org OR b) generates less than 1000 tile requests per day I accept the spirit of the suggestion, but 1000 tiles is probably a bit conservative. There is a level at which (IMHO) we would prefer low volume applications of whatever sort to use OSM instead of Google etc. even if that comes at the cost of tile accesses on OSM servers. I suppose my rule of thumb would be that the human eyes looking at the third-party application would be no greedier than had we had those same eyes on the main OSM site. In such cases, assuming correct attribution, such sites are providing us with welcome publicity and we need not be mean with our tiles. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Quick History Service
On 23 April 2011 21:29, Frederik Ramm frede...@remote.org wrote: I have built a narrowed-down database that keeps a list of all objects and their editors. Because it keeps nothing else (no concise object histories etc.), it is reasonably small and fast (the MySQL database takes 55 GB on disk for all objects). Data is updated every minute. Huge thanks for building this - it's almost exactly the service I had been missing and threatening to write, and now I won't have to. I see that user names are not provided. Is that for reasons of discretion, volatility or performance? Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: [OpenStreetMap] ODbL
On 10 January 2011 11:41, John Smith deltafoxtrot...@gmail.com wrote: What's it going to take to stop people spamming me about the ODBL? One man's spam is another's contact from one community member to another. Put differently, if you edit the map data in somebody's area, you have no business getting offended if the somebody has occasion to contact you on a matter of importance to the local map. From my own observations in my own country, your edits will be causing a small but noticeable amount of community effort come licence change. We'll have to accept that. It's not impossible that some of my local mappers might even contact you about it - not me, because I happen to be aware of your feelings on the matter. But, y'know, if you aren't prepared to talk to people, you should possibly avoid participating in communities... Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: [OpenStreetMap] ODbL
On 10 January 2011 14:13, John Smith deltafoxtrot...@gmail.com wrote: What about the proactive community against the license change, or don't they/their views count? You haven't forgotten that such users hold the ultimate sanction? They get to withhold their own work _and_ that of others unfortunate enough to build on their foundations. So there's very little chance that the opponents will be ignored. Quite the reverse will be the case, I expect. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: [OpenStreetMap] ODbL
On 10 January 2011 16:40, Anthony o...@inbox.org wrote: When the data was submitted it was submitted on certain conditions. One of those conditions is that people who build on the foundation of the contributions have to give others the same freedoms as they have been given. Indeed - though there are cases where ODbL non-acceptors have made edits in the middle of an object's history, or where a crude original by a non-accepting editor has spawned a useful, but still tainted descendent. And that's fine - we all understand that we have to accept this kind of setback as the cost of progress. But it does serve as a guarantee that nobody will be sidelining the licence skeptics any time soon. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] scaling
On 9 January 2011 22:35, Frederik Ramm frede...@remote.org wrote: This was not purely a techical issue. If we were set up, technically, to handle something like what you're describing here, the eternal september effect would kill off the community for good. That depends very much on how you tell the users from this major new source to edit and on the sort of edits you solicit from them. To be sure, if you overnight increase the rate of newbie arrival by an order of magnitude, and if you then do as we have always done, saying newbies, allow me to introduce Potlatch and JOSM. Oh, and Map Features is that way, now be sure to connect all your nodes, then things will get a little chaotic. But it doesn't have to be like that. Again, we don't know what kinds of users these are and Steve's not telling, but Let us suppose they are not hardcore map geeks, because such people are quite likely to have found us already. A less ambitious mapper can get by with higher-level tools. Indeed, a mapper who manipulates, say, only POIs, you could even get by with a not-quite-live submission tool. Heresy, of course, but hey, you could do it... Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] scaling
On 10 January 2011 00:07, Frederik Ramm frede...@remote.org wrote: Certainly. But that would then not require the kind of massive scaling that Steve was hinting at, would it? To take that level of newbies and point them at today's toolset might indeed require a lot of scale, though I admit I was more concerned about the social effects. As such, defining a simpler, less dangerous workflow for such users helps to buffer the database - both from sheer load and from potentially bad data. We are already overdue such a process, TBH. Whereas we have some pretty good tools, like the Mapzen POI collector, there isn't a comprehensive process of the sort that would, for instance, help avoid the use of a POI collector to upload yet another copy of the same hotel. Indeed, when I read your post, Frederik, I suddenly got a shock. You do have a point, but if we follow your reasoning through to its conclusion we should already be discouraging (most kinds of) newbies from joining OSM, simply because we don't have the (social) infrastructure to sustain them without damage to the map. Many of us have observed the phenomenon in our own communities - a new mapper arrives on the scene, craps all over the map and vanishes. You always used to get an element of this. As time goes by we get more and more. And that, as you would probably be the first to point out, is fine, the Community can cope, and that's why we have to be cautious in our growth rate. I would counter that this is insufficiently ambitious. I'm not talking here about gung-ho ambition to have the most impressive graph of contributors. Simply that if you can't carry the water to the fire as fast as the tap can dispense it then there are alternatives to closing the tap a little. You could get a bigger buckets. Or more buckets and some pals to help. Or maybe get a hose. I don't know yet what our hose would look like. But if we have empty or broken bits on the map... And if we have the option of getting more people to work on them... And if we find ourselves tempted to turn them away or to stall them a bit... Then we would surely be better served by diverting some effort to finding ways of boosting our social scale instead. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Microsoft gains access to aerial imagery
OK - I said I'd post again with my intentions. Here is a wiki page that I hope will outline the automatic imagery adjustment mechanism I've worked out with another mapper: http://wiki.openstreetmap.org/wiki/True_Offset_Process Comments are welcome. By now we're happy that we've described something worth building, and we hope to have something to show off fairly soon. Cheers, Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Hack day
On 8 March 2010 18:15, SteveC st...@asklater.com wrote: Thanks Tom, I've added the 14th at the bottom of that page and linked it from the calendar. Hope people can come. I'll be along too - Steve, the wiki page says to call you for access to the building. I assume this is your listed UK number? Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Whitespace in tag-keys
2009/9/13 Martin Lesser ml-osm-...@bettercom.de: I did not find explicit informations about this issue in the wiki so I'm wondering whether whitespace in keys is a should not or a must not. I think you're in fact addressing two separate issues here. As we can see, the API will allow you to place whitespace in keys, but IMO this is certainly a should-not case. Doing so, particularly as leading or trailing space as in many of your examples, just confuses people. But onto your examples: What's the recommended action if one detects tags like eg. http://www.openstreetmap.org/browse/node/275671906 (k=is in) http://www.openstreetmap.org/browse/node/447654517 (k= type) http://www.openstreetmap.org/browse/way/38170057 (k= v=residential) http://www.openstreetmap.org/browse/way/39240565 (k= v=Gweyn Hughs Road) These are just cases of broken data. Broken in the sense that all clearly intend to record data of a kind for which very established norms exist but that fail, presumably accidentally, to conform to those norms. In a case like this, the data should be altered. Tools like the JOSM validator already treat such cases as breakage and flag them for the user. These cases are comparable to typos (higway=primary) or failure to stick to lower-case (Name=High Street). These too will yield unexpected behaviour and should be fixed. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Cloudmade routing for OSM rails_port site.
2009/4/29 Frederik Ramm frede...@remote.org: *If* our user base thinks that routing is a need they want met by the OpenStreetMap site, which is something that should be discussed. There's another angle to consider here - we don't just need to cater for our existing user-base (who are probably quite a resourceful bunch). One of the reasons we have a site with a slippy map on it is that it demonstrates to those unfamiliar to the project what OpenStreetMap is capable of. That our slippy map closely resembles those of Google, Yahoo and others helps to get around any scepticism that might arise. This is why it is, IMHO, important that the map be draggable rather than click-the-edge-to-pan-and-reload. AJAX-powered maps are considered a baseline user requirement. Clearly every potential user of OSM is different, but for me, a key benefit when I discovered the project what hey, vector data, that can be used for routing!. If we think that others discovering the project would thing likewise then a prominent path from project home page to a routing engine (and I really couldn't care less whose) would be a Good Thing. As long as it works acceptably well, of course... Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Cloudmade routing for OSM rails_port site.
2009/4/29 Frederik Ramm frede...@remote.org: But isn't this angle one where the open/closed distinction gains weight again? Currently, you can (and I've done this a number of times) tell potential OSM users: Everything on openstreetmap.org is free software and free data - you can build the exact same site for yourself with all its functionality from our database and our svn *). With non-free routing or geocoding services that would stop. Actually yes, I think I overstated my lack of caring where the routing comes from - let me restate my priorities thus: 1. That we should have at least one routing engine to show that our data will support that. 2. That we should have a selection of routing tools to demonstrate that the data are engine-agnostic. 3. That a good proportion of the engines we show off be sufficiently open to allow users to play with them or deploy them for their own needs. 4. That our headline routing engine be open. That is, whereas I have a preference for an open solution, so that people get used to the idea that such problems can be solved using open software, I personally wouldn't insist on it if (as I believe) we are selling ourselves short without any on-site visibility of routing tools. However, I can understand that others would put my priority 4 right up the top of the list. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Commit message not empty
2009/4/23 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: In JOSM however, we can ease the user in maintaining a self updating drop down box, and a number of standard comments with . behind it to stimulate completing. Updating highways .. (user fills-in :) Updating highways = cycleways near Moskou I've had some ideas along similar lines, though I see more automation being used. Like Frederik, I think that comments are important - important enough for us to strongly encourage mappers to use them and appreciate their value. So I figure we should try to devise a repeatable, automatable style of default commit message which would be proposed to users prior to upload (in JOSM - Potlatch could silently use it if desired) with an encouragement to adapt or replace it with something better. Possible formats: Small|Medium|Large update within x km radius of lat/long Update of x nodes, y ways, z relations within n km of town or city Adding town or city names for better orientation makes it a lot better, and would be feasible without external lookups in any cases where the downloaded data set contained any place nodes of significance. What do people think? My intent here is that the automatic guessed message would be as close as feasible to the kind of informative message you'd like the user to learn to use. (I'll duck any patches welcome answer right away by disclaiming all Java skills, but hopefully somebody else will value the idea enough to try coding it). Cheers, Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
2009/4/23 Frederik Ramm frede...@remote.org: Almost worthless, I'm sorry to say. Any automatic message can just as well be filled in later by some automatism on some server that compiles and anlyses changesets. What we're after is the human bit that no machine can replace! A little harsh :( Lest I've been misunderstood... That you could retrofit such an automated message is clear. For me, the value of computing it at commit time is that it can be shown to the mapper as a default. The intention being to trigger the following kinds of thoughts that he would not think if faced with an empty text field: * Oh, I can add a comment. * Ah, so that's what comments are for. * Ugh! That commit message is a bit crap. I'll replace it with a better one. * No, my edits aren't centred on Mistfeld, I was actually mapping mole tunnels, I should make that clear. Now, if we think a default message wouldn't have this effect, then I certainly don't think we should add one just for the sake of the information it would add to the log. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] webkit-image on Mac OS X
2009/4/19 Stefan Bethke s...@lassitu.de: I'm currently trying to get webkit-image to work on 10.5.6. Just so you know - I've done this and it works. I can't go into details now (I'd have to remember first what I did), but if you can't make it work I can either send you a binary or try to help make the build work. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Keep Right - some permanent false positives
2009/3/8 Ulf Lamping ulf.lamp...@googlemail.com: b) This way is tagged as motorway and therefore needs an int_ref tag A lot of German motorways only have a ref like the one here in Nürnberg A 73. Let me add to that the insistence that motorways should have a nat_ref. In many countries, including here in Ireland, motorways have one single reference which we tag as ref, and _sometimes_ (as per Ulf's point) an int_ref E-number too. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keep Right - some permanent false positives
2009/3/8 Harald Kleiner e9625...@gmx.at: Hi Ulf, Maybe I'm completely wrong, but I thought, the inner way should be tagged with building=yes You _are_ completely wrong ;) It is permitted to tag the inner way, if it in turn contains something that ought to be tagged (a lake within a forest, say). To tag the inner way of a building suggests that there is one building contained within another. There has been a very confused history of how renderers deal with holes, and for some of that time, some renderers have required the inner way to be tagged, but this was never the intention. Your suggested change in the motorway ref rules sounds good to me. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Trouble translating JOSM: Same strings used in different places
The issue of localisation frameworks is one that I've been considering a lot in the last few weeks in my day job. Our application is built in perl, and perl provides a more powerful, code-allowed tool called maketext which does more or less what gettext does but with some extra bells and whistles. There are ways to use the .po file format for a maketext lexicon. Some background: http://cpansearch.perl.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.62/docs/webl10n.html But the one thing that surprised me is that all common lexicon arrangements assume that strings should be keyed not by an abstract key (like, say, EDIT_MENU_NAME, 'EDIT_TOOL_BUTTON_NAME) but by the string itself in the primary language (Edit, with no option to have a second Edit in a different context). This struck me as troublesome during my investigations, partly because of the context difficulty that we're seeing here, but mostly because for a string like ACME Widgets company - your source of cheap widgets, any change, even one of punctuation, or, in this example, a revision to your English language slogan, forces an update of all localised string assets, whether or not it's essential that they be adjusted (which for reasons of English punctuation or grammar or single-market motto changes is more trouble than is warranted). Has this kind of problem not arisen many times before and been solved? Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OGC standards / Sql Server 2008 / OSM... help?
Hi Brendan, I've just looked at the piece of coastline in question and found two errors in it (both now fixed): * There was a duplicate node * At a different place, the coastline overlapped itself. I can see how these (particularly the overlap) could be confusing to the DB. It may be worth trying it again with the new data. Dermot 2009/2/18 brendan barrett shogun...@gmail.com: Hi I've just signed up to the dev mailing list, and hopefully i'll catch up by reading the archives. For now though I have a question and please don't follow up with insults if you see the names Microsoft or SQL Server :P I'm trying to render coastlines in an application that I am building. The concept is simple: find the lines, and join them end on end until you get an area. Now my problem is with OGC standards. I'm using Sql Server 2008 *ducks for cover* and more specifically the new Sql Server Spatial types (Geography and Geometry). Sql Server 2008 seems to be pretty strict with OGC standards, and I am but a beginner when it comes to OGC standards. The problem i'm having is with some coastlines in OSM that double back on themselves. Like this one: This way http://www.openstreetmap.org/browse/way/13858554 doubles back on itself with this node http://www.openstreetmap.org/browse/node/130020792 having the same latitude as this consecutive node http://www.openstreetmap.org/browse/node/130020793. I think this is the reason for the way being invalid in Sql Server's eyes. The MS folks have included the MakeValid() function which corrects the way to comply with OGC standards, but this changes the latitude and longitude of every point in the line ever so slightly, and that's not desirable if you are matching ways end on end. I can use the Node Ids to match them, but the bigger issue is that my data is invalid and I can't use other spatial methods on it. I have 4 questions: 1. Is this doubling back really an OGC restriction? It makes sense that these ways don't double back because it doesn't serve any purpose for a coastline (or for any line, you would expect even a path that doubles back to be at least some distance apart, or simply labeled two way). 2. If this is a problem, is it something that will be fixed in the editors / the API? 3. Is there anyone else here with experience with SQL Server 2008 Spatial and OSM that might have some tips on dealing with all these ways? 4. Does PostGIS have these types of issues? I'm thinking that the only way for me to deal with this is to correct the data in OSM (if it's clearly incorrect) or in my database once imported (if there's no other solution). Thoughts? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OGC standards / Sql Server 2008 / OSM... help?
2009/2/18 brendan barrett shogun...@gmail.com: Is correcting it inside OSM the only way to deal with this kind of data? Well, I can't speak for SQL server, but this kind of data is something we're usually prepared to call wrong for all kinds of other purposes. It's certainly the kind of thing that has broken coastline rendering in the past, caused flooding and suchlike. So fixing it is The Right Thing. If so, i'm thinking of compiling a list of all the ways that do not comply, and then posting them somewhere so that we can all pick them off one by one. There are a lot in Australia alone (using the aussie export to get my testing done). I have a feeling that anyone using Sql Server Spatial will have these issues. A noble idea. Automating it is the way to go. I cleaned the Irish coast of defects like this by hand. It took quite a while and there's somewhat less of it than there is in Oz... Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] zoom support in new wms plugin
2008/12/21 Dirk Stöcker openstreet...@dstoecker.de: a) I fixed the WMS displacement so it now again displaces the whole map and not a single image, but I did not get the display right. The visible/unvisible decision is still done based on the unmoved pics. (I can live with the fact that loading is done based on original position, but don't understand why the display is done likewise). Nice to see us return to previous behaviour here. b) The plugin should use caching. Maybe we can turn it off for Yahoo or clear yahoo cache on each program start, but a normal download cache is required for the autoloading/autoremoval. Can the webkit image not cache the tiles it downloads? If it could, surely this is identical to how, say, Firefox or IE would cache images, and if so, it should keep us within the terms of Yahoo's conditions of use. As an aside, has anybody managed to build the webkit image on MacOS? I've come unstuck on one of the qt libraries, even though QT is installed. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Automatic tiles downloading in WMSPlugin
2008/9/1 Petr Dlouhý [EMAIL PROTECTED]: To render the pages I am using gnome-web-photo application, which simply saves the png image of the website to file. The problem is, that this application is only for Linux. I need to find similar application for Windows, so if somebody knows about it, please write me. From first appearances, it should run on more than Linux. It appears to be available as a FreeBSD port and looks like it should run on any other UNIX-like system. I'm having a go at building it on my Mac. It your approach works, it will be a big improvement. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
2008/8/20 Gervase Markham [EMAIL PROTECTED]: I think that both waterways and roads are layer 0, the ground, and when one crosses another, the upper one should have layer=1 - because there's air between it and the actual surface of the earth. I would apply this to any ground-based physical features, not just roads and rivers. That articulates my view pretty well. Once again, consider that layer isn't the same as level. We don't care whether a bridge rises up above the level of the road either side of it. The important thing is that at the point where it crosses the river, the road must be on a higher layer than the river. So along the length of a way, it is acceptable (and unavoidable) to have jumps in layer that may not reflect actual changes in elevation. Layers exist to determine the drawing order of overlapping elements, nothing more. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Bug 595 - Virtual nodes - Comments requested
2008/8/18 Petr Nejedly [EMAIL PROTECTED]: I just don't like the appearance of the virtual nodes. Could you turn them into small (nonzoomed), thin red plus signs instead of rendering them the same style as the way they sit on? I love this new functionality, which as you say, is perfect for adding detail to jagged ways. However, I agree with Petr. Having the plus sign in the style of the way itself makes it look almost like the direction arrows, where it should have a similar treatment to nodes themselves. I'll continue to use it in the meanwhile, though. Thanks, Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Slippy Map Chooser broken?
Hi folks, Is anybody else having trouble with the slippy map chooser plugin? I've just updated to josm-latest for the first time in about 2 weeks, and have updated my plugins too. I have traced the problem to the slippy map chooser plugin as per #1422. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
2008/8/16 Dirk Stöcker [EMAIL PROTECTED]: This information is shown in the ToolTip. You get this when waiting a short time over the error message. Ah yes, so it is... It does force me to mouseover each violation, though. For a large or detailed area, this is going to be very impractical. Actually this is already implemented. It's only moved to the ToolTip for two reasons: a) There is so little space there in the Validator window True - but to me, the existing top-level message isn't actually useful, and could easily be replaced with the more specific message. Furthermore, if I decide (as I am likely to) that it will be generally acceptable for tertiary roads in my area not to have ref attributes, I would value the ability to collapse and ignore a whole set of violations. As it is, I'm going to have to search through a list of acceptable violations to find the ones I really care about. b) When I change the generic error message, the valdition dialog will be filled with lots of different message types. This makes finding certain types more difficult. Which types? As far as I can see, the only violations that will be separated based on my suggestions are the ones that are already unlike each other. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
2008/8/16 Dirk Stöcker [EMAIL PROTECTED]: Ah yes, so it is... It does force me to mouseover each violation, though. For a large or detailed area, this is going to be very impractical. Suggestions welcome. I'd still favour my original suggestion - rather than group all of these new errors under the single label they now occupy, group them instead under their respective, detailed, labels. That keeps un-reffed road errors away from, say, typoed landuse errors. But ultimately, what I'm saying is lose the tool tip, at least for information like this. A good rule of thumb here, would be that tool tips are good for followup information that might not be necessary in all cases, or for inexperienced users. But you shouldn't put data behind a tool-tip that is necessary in order to make use of the error message. You can ignore them once and for all the time :-) I haven't yet worked out the full scope of the ignore option - but it doesn't seem to ignore all similar cases, only the specific object I have selected. In any case, some violations are things that you care about (like missing refs) but can't always do anything about. (like tertiaries, where it can be difficult to determine the correct ref). Don't know how make an ignore for specific tests in the test-set. But it's a new feature. Give it some time to mature. For sure. Lest there should be any doubt, I really like what you've done here. I'm just struggling with aspects of how the results are output. Yes. The other validation types. Think of e.g. 30 different TagChecker types and one unclosed way. You wont find it in this batch of TagChecker stuff. I'm not sure I see what you mean here. It doesn't matter to the user if a crossing way or unclosed area message isn't generated by the tag checker, even if another 30 messages are. Each violation message represents something that the mapper needs to review and either repair or accept in its current state. Do we really need to contain the tagchecker messages behind an overall label? Maybe there's a technical reason, but it feels unnecessary from a UI perspective. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Filled roundabouts
Hi folks, While at SOTM I updated to the latest JOSM, to discover a new feature. Roundabouts are now displayed with a dark green fill, but (the important bit) _without_ the outline colour correctly reflecting the classification given in the highway tag. Is this intentional/considered useful or is it a side effect of another change? I don't really mind the fill (in fact, it's a useful visual clue that allows us to spot roundabouts not correctly tagged as such), but losing the highway colour is a pain. Cheers, Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Translation into german
2008/7/3 Till Amma [EMAIL PROTECTED]: Freizeiteinrichtungen To me, that translates back to English as Leisure Amenities, making it overspecific. Think of courthouses, fire stations, fuel stations, none of which are strictly related to leisure. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] Presets
2008/7/3 Dirk Stöcker [EMAIL PROTECTED]: access=destination and Wow. Hard to translate this with one word. Anyway managed to do translation nevertheless. Isn't this the same as Anlieger Frei? In fact, it's a concept I've only ever seen applied in Germany. Dermot -- -- Iren sind menschlich ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [OSM-dev] Lake data from SWBD
2008/5/14 Ludwig [EMAIL PROTECTED]: Unless someone objects I will upload the SWBD data for an area I am otherwise mapping and where no lake data so far exists - I have no intention of trampling on other people's work.. That seems very reasonable. If subsequent mappers don't like the results, they can easily fix things up themselves. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Lake data from SWBD
2008/5/10 Ludwig [EMAIL PROTECTED]: Is there a reason (other than nobody has done it) why the lake data in this data set has not loaded into OSM? Are there objections to this data being uploaded for lakes only? I looked at this source for Ireland - mostly with rivers in mind, but I did look at lakes also. What I found wasn't very impressive. Even though Ireland is relatively full of lakes, it was easier to get good results using the lakewalker script (and, more recently, plugin). For small lakes, the inaccuracy of the data makes it unattractive. For the larger ones there's not that much point, since a morning with lakewalker will give you something that you have at least visually verified against landsat. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] See Data, a UI for browsing OSM data in the main map
2008/4/23 Lauri Hahne [EMAIL PROTECTED]: Isn't that what's Potlatch for.. (if we forget that P. is malum in se (or at least used to be)) Perhaps - but consider the two biggest points of agreement between all on the Great Potlatch Debate: 1. It offers the most immediate way to update the map data 2. It offers the easiest way for newbies to make a mess. There are people who would be very able and willing to enter missing street names and correct typos, but who would not have the editing skills to avoid moving nodes around by mistake. A higher-level tool that exposes only the most important meta-data is very useful. In fact, I'd imagine it shouldn't even allow just any meta-data changes, at least by default. I'm thinking more of a tool that allows users to edit specific fixed attribute values: name name:xx ref int_ref (other refs) place (maybe, but if so, constrain values to the valid ones) oneway (likewise - I saw a street yesterday with something like oneway=yes (south and west)) My instinct is _not_ to expose even highway, but no doubt others will disagree. One last point - there's no reason that Potlatch couldn't do all these things using a dedicated move-nothing mode, it certainly offers a lot of opportunities to reuse the preset selectors. Dermot -- -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] See Data, a UI for browsing OSM data in the main map
2008/4/22 Christopher Schmidt [EMAIL PROTECTED]: As I said in the first email: Oops. And the silly thing is, I'd read your mail through and still somehow missed that bit. I'll refer you to my well timed signature change below :) Cheers, Dermot -- Iren sind menschlich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [josm-dev] Mac .app
On 28/01/2008, Frederik Ramm [EMAIL PROTECTED] wrote: I occasionally use a Mac as well. I have the .jar lying around on the desktop, and double-click it to start JOSM. What advantage does a .app have over this? One drawback of starting it like that is that you don't get to boost the memory available to JOSM, something I've found I usually want to do. For that reason, I usually end up starting JOSM from the command line on my own Mac. I don't know if Till's .app technique can help here, but if it can that would be a clear benefit. Dermot ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [josm-dev] JOSM mini-roadmap anyone?
On 23/01/2008, Gervase Markham [EMAIL PROTECTED] wrote: The normal fix for this sort of problem is a drag threshold, whereby you have to drag an item a certain distance before it will break free and start moving. Was this solution considered? It was one of the suggestions at the time. Some folks had concerns that it would make it difficult to do small position nudges. Also, it would have required some tuning to be sure that it worked as expected at all levels of zoom (you want it to be a distance-on-screen threshold, not distance-on-map). I'm not sure what triggered the final decision to favour a time threshold, but Fred did the work... ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
