Re: [Talk-us] Tagging National Forests
On Thu, Aug 20, 2015 at 10:22 PM, stevea stevea...@softworkers.com wrote: John Firebaugh writes: The political boundaries of US National Forests should not be tagged landuse=forest unless the entirety of their area is land primarily managed for timber production. I venture to assert that this is not true for *any* of the National Forests. Here are some examples of areas within National Forests that are not primarily managed for timber production. OK, so say so where so. (Tag in OSM accordingly). If you wish to subtract from the polygon areas which you are absolutely certain no timber production is allowed or possible, go for it. It wouldn't be correct to exclude areas where no timber production is allowed or possible from the multipolygon indicating the political boundaries of a National Forest. That would mark such areas as not included inside the boundaries, when in fact they are included. There should be (at least) two separate entities in the database. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging National Forests
The political boundaries of US National Forests should not be tagged landuse=forest unless the entirety of their area is land primarily managed for timber production. I venture to assert that this is not true for *any* of the National Forests. Here are some examples of areas within National Forests that are not primarily managed for timber production. http://julialanning.com/files/2011/09/A-Plains-Rainier-RSZ.jpg This is a pumice field in the Plains of Abraham near Mt. St. Helens. It's not producing timber, and is not being managed to so as to do so any time soon. Mount St. Helens National Volcanic Monument lies within Gifford Pinchot National Forest. https://upload.wikimedia.org/wikipedia/commons/2/22/6507-ShastaLakeFull.jpg Shasta Lake, part of Shasta-Trinity National Forest, is the largest man-made lake in California -- 4,552,000 acre·ft at full pool, though significantly diminished as a result of the drought. None of the lake area is being primarily or even partially managed for timber production. https://upload.wikimedia.org/wikipedia/commons/9/91/Mendenhall_Glacier_%28Winter%29.jpg It won't be possible to produce timber in the area currently covered by the Mendenhall Glacier, in Mendenhall Glacier Recreation Area, a unit of the Tongass National Forest, until global warming significantly advances its melting. It may be sooner than we think, but not today! http://timberlinetrails.net/sitebuilder/Photos/Whitney/EastFaceRoute.jpg The East Face of Mt Whitney, in Inyo National Forest, features one of the world's classic rock climbs. The route lies entirely above 13,000 feet, and climbers on it will be hard pressed to find any substantial vegetation at all, let alone anything that could be used to produce timber -- or even firewood. Even if you happen to believe that personal wood-gathering for building a fire constitutes timber production -- and I, like Frederik, think that this definition is patently ridiculous -- there are many areas within National Forests where it's impossible to do so. We should be tagging the areas within them, where timber production is happening or at least possible, as landuse=forest, not the entire political boundary. On Thu, Aug 20, 2015 at 9:57 AM, stevea stevea...@softworkers.com wrote: On 08/19/2015 07:25 PM, stevea wrote: This isn't extreme. Your backyard activity is consistent with the definition of a forest: a land which is used for the production of wood/lumber/timber/firewood/pulp/et cetera. Frederik, Frederik, Frederik...where do I begin?! According to our wiki, which I DO follow when there is ambiguity or any question about what or whether I should map something, landuse=forest is used to mark areas of land managed for forestry. As I have said here before (recently), this is EXACTLY, PRECISELY what a USFS national forest is. If we change what tags mean in this project, we ought to have a better set of tags to use instead, and we are some distance from that. There is a problem with this definition; it is too broad. I use the wiki definition I note above. Consistently. Even on polygons from local zoning/cadastral data marked as Timber Production in my county. Whether there is active felling of trees or not. The heart of the matter here is quite likely that the wiki definition for forest is overloaded: OSM uses at least four different interpretations as the wiki outlines. A solution to this problem might start with consensus-based re-definition, followed by consistent (worldwide) application of the new method, and rendering support to see what we have done. That's a lot of work we ought to get started doing. Even the seabed can fulfil some of these uses and we don't want to tag forests in the sea. What the heck? I know of no trees growing on the seabed! (Although if there were an odd tree, say near the shoreline of the sea, I agree with a natural=tree node there -- but I don't think I've ever seen one). This definition of a forest is unsuitable for OSM and should not inform our tagging. (Luckily the Wiki, which is not always reliable on these issues, says: A forest or woodland is an area covered by trees., and not: A forest is an area where you could potentially find something to light a fire with.) Please don't twist what I say, conflate my meanings or read into what I have written, as it appears you have. What I have done is apply the wiki definition (area of land managed for forestry) to USFS polygons. Stick to that and tell me I'm wrong, because I don't believe I am by that definition and application. There is also a problem with your interpretation of this already-unsuitable definition; you say that if land yields wood for any reason, it is used in the production of wood. But I see a difference here between scavenging and agriculture. Just because there's wild berries somewhere, doesn't make the area an orchard. Just because you are legally allowed to pick up a branch that
Re: [OSM-talk] iD name suggestion index - asking non-English-speaking mappers to review
Over the weekend I merged all outstanding pull requests. These changes will get picked up automatically in the next release of iD. Thanks for the contributions, please keep them coming. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] Using OSRM linked into other code?
Hi Steve, Recent versions of osrm-backend build a library which you can link against. See https://github.com/Project-OSRM/node-osrm/ for an example. cheers, John On Fri, Nov 7, 2014 at 7:13 AM, Stephen Woodbridge wood...@swoodbridge.com wrote: Hi, I seem to remember a while back that there was a discussion about the possibility to embed the OSRM routing engine at the code level rather than doing HTTP requests to a server. I now find myself in a position that this would be desirable to do. I have a small coverage area like a city, but I'm getting killed by the overhead of formatting requests as strings, making a socket connection to osrm-routed, parsing the responses, etc. Making local requests my server this is taking 4-500 ms per request. Basically, I'm doing viaroute requests with 2-100 via points. 99% of the time all I need to know is the travel time. Since I'm developing in C++, I thought it might be easy and much faster to instantiate the routing engine and then have a simple interface where I can pass a container of points and get back the travel time for that route and/or the path coordinates. But I could live without the coordinates if I had to. Has anyone done this already? Can you share? I have started digging through the source to see if I can do this, but working my way in from osrm-routed or Tools/simpleclient.cpp the code is very entangled with all the http request/response stuff that I would ideally like to avoid. So far the most promising path looks like using some variant of the simpleclient, but its not obvious if or how to untangle all the json stuff and simply return a struct or class to the caller without that. I spent most of yesterday, digging through this and made a lot of progress just understanding simpleclient and getting ti to compile and work and get it to actual return results using a shared memory connection. A little help in this direction would be appreciated. Thanks, -Steve ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk] iD usability test results
Hi Jan, Thank you for your work; rigorous usability testing of this sort is quite valuable. I've skimmed parts of your thesis and will read it more thoroughly this week. I think there are many improvements we can make to iD based on your findings, and we are starting to open tickets on them in the issue tracker. cheers, John On Thu, Sep 25, 2014 at 3:57 AM, Jan B antof...@gmail.com wrote: Hi all, earlier this year I announced my thesis work on testing the usability of the iD editor. Thanks to many community members who volunteered as test persons I have been able to complete the study with success. The thesis is now available for download: http://media.obvsg.at/p-AC11999640-2001 I hope the findings of my research will be useful in the further development of iD. I welcome your questions and comments. Cheers jan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] vector::_M_range_check error
Hi Matthias, One thing to check is that the data files being used were generated with the same version of OSRM. I have seen this error when a 0.4.1 server used data files generated with 0.3.9. John On Thu, Jun 19, 2014 at 5:33 AM, Matthias Schwamborn schwamb...@informatik.uos.de wrote: Hi all, I've set up my own OSRM server (v0.4.1) and encountered the following error several times so far (for different (src,dst) pairs): [warn] [server error] code: vector::_M_range_check, uri: /viaroute?loc=55.76191121265607,37.599698264694666loc=55.76045290194501,37.59812508836046z=14 I also tried getting more information by compiling osrm-routed in debug mode, but to no avail. Any pointers to what this error means and how I can avoid it? Thanks. Best, Matthias -- Matthias Schwamborn University of Osnabrück Tel.: +49-541-969-7167 Institute of Computer Science Fax:+49-541-969-2799 Albrechtstr. 28 E-mail: schwamb...@informatik.uos.de D-49076 Osnabrück, Germany http://cs.uos.de/schwamborn/ ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [Talk-us] Why we really don't get new users
Hi Charles, Have you looked at iD's preset-based feature editing UI? It's very close to what you describe: - Machine readable ontologyhttps://github.com/openstreetmap/iD/blob/master/data/presets/README.md - Search-based UI - No detailed knowledge of tagging schemes necessary - Customized UI for specific fields We haven't yet gotten to the level of detail necessary to support query terms as specific as bagel, nor to cover the immense complexity of the opening_hours format, but contributions are welcome. A related project is the Name Suggestion Indexhttps://github.com/osmlab/name-suggestion-index, which provides automatic tags for search terms like Walmart or Raiffeisenbank. John On Mon, Mar 17, 2014 at 11:17 AM, o...@charles.derkarl.org wrote: I'm going to just point out the elephant in the room here. I don't think any normal user cares about the license at all. I think the actual reason its hard to get new mappers, especially those that are not nerdy and obsessive like myself is that *the ontology sucks*. There, I said it, so you don't have to. It's actually a few things related to how the ontology sucks: 1. The tagging of things bears little resemblance to things in the real world: a. A lot of common things just don't have standard tags: examples: tax preparers like HR Block, investment brokers like Charles Schwab, medical marijuana despensers here in California, recreational MJ shops in Colorado. I could go on. b. the whole shop/amenity debate c. common things that have really stupid tags, like barber shops 2. To be a useful mapper, one needs to memorize these arbitrary tags. It wouldn't be so hard if it weren't arbitrary (a salon is a shop? and it's called a hairdresser‽). But even if it weren't arbitrary, it'd still be hard to remember because things have synonyms, and no shop is called a chemist in the US. Corrolary: A bagel shop is a bagel shop, no muggle cares that a bagel shop is fast_food amenity that sells the bagel cuisine. 3. I went to a shop recently that sells espresso drinks, and gelato, but markets itself as a chocolate maker. (Specifically: Snake Butterfly, Campbell, CA). There is absolutely no sane way to tag this in OSM today. 4. The wiki is a terrible platform for documenting the ontology because it's not machine readable and it's just a slow way to get information. I don't just mean to moan, though. What I'd like to do is propose a machine- readable ontology that we could provide to JOSM, Vespucci, etc, that would allow newbies to edit the map. I imagine a dictionary and associated tags. A user could type in bagel and all the reasonable properties show up, along with a description of what they're entering: (A shop that sells primarily bagels, baked goods and breakfast foods) (not what you're looking for? try bakery or diner) name: [ textbox ] opening hours: (a *UI* to enter times of week) vegetarian ( ) friendly ( ) unfriendly ( ) exclusively house number: [ textbox] etc And by filling these properties in, the software would automatically convert it to the OSM ontology. All the client software would need to do is be able to parse our ontology file to provide all of this. And provide a sane UI, at last, for entering opening_hours. Charles ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] The new OpenStreetMap.org design
This past weekend, the OpenStreetMap.org front page launched with a new design. This was a big step for a site whose design hasn't changed much in 7 years [1]. The goal of the redesign was to make the site more inviting for newcomers, easier and more efficient for veterans, to clean it up and refresh its looks, and to resolve a number of longstanding usability issues and bugs. See for yourself - before Friday last week: http://cl.ly/image/1P3f2N2z0b0p Since Friday last week: http://cl.ly/image/350W0v023A0u Concretely, here are the improvements we implemented: - A better experience for new contributors. There is now a concise explanation of what OSM is and an invitation to get involved that isn't lost in the noise of other elements competing for attention. Secondarily, the new help and about pages provide a dedicated place to expand on that initial introduction -- something that simply can't be done effectively in the confines of a sidebar. - A better experience for veterans. There's now more space for the map and a sidebar that functions efficiently for the task at hand, whether it be searching for a location, browsing data, or reviewing changes. There's no longer a needless distinction between browsing a feature and viewing it on the map. And navigating between features and changesets is fluid, fast, and preserves more context. - A modern look and feel. While there is no doubt design is to some degree subjective, the fact is that any design communicates a message. In short, the old design looked dated, haphazard, and uncoordinated. The new design aims to communicate the fact that the OSM community is alive, growing, experienced, and competent. One comment on the pull request said the new design looks way too 'professional' for a community website -- well, I think that's a good thing. :) - Bug fixes and usability improvements. Most notably, the site works much better on mobile devices. For other fixes, see the linked issues at end of the pull request ([5]). It's noteworthy what we didn't change: - We didn't add or remove major features - We didn't change the logo or color scheme - We didn't change the prominence of key features such as viewing, editing or browsing changesets - User profiles, diaries, messaging, and other interior pages have seen only minimal changes This work brings to culmination a process that involved multiple talks and birds of a feather sessions at conferences [2], conversations on mailing lists [3], several previous design iterations [4], and the longest pull request in the history of OpenStreetMap [5]. A big thank you to everyone who's been involved in making this happen. This effort involved many hands. From my colleagues Saman, Eden and Aaron who laid out the design and slugged through many lines of code to get the pull request ready to merge, to Tom Hughes who helped reviewing and got the pull request ready to launch in one last final push. A big thank you also to anyone who helped along the way with reviewing, testing and pointing out issues -- it greatly helped improve the result. This redesign is a leap forward, but not the end-all be-all. There is most definitely room for improvement, and constructive feedback and hands-on help is always welcome. If you'd like to get coding on OpenStreetMap and you'd like a hand, please hit me up on IRC. If you're looking to file an issue [6], please follow these steps: - Describe the problem rather than a particular solution. It is much easier to communicate if there is a common understanding of the problem that should be solved. - Be as specific as possible. - Search for existing reports. - Use a good title :) In the days since the launch on Saturday the openstreetmap-website issue tracker has been busy with adjustment and polish work. Here's a run down of key fixes: - Added a close button to the welcome message for non-logged-in users - Restored support for bbox and min/max/lon/lat URL parameters - Fixed opening browse links in a new tab or window - Fixed cosmetic issues with long tag keys or values - Fixed errors when clicking on certain search results - Fixed issues with changeset feeds Tom, Aaron and I will continue to look at important remaining issues in the days ahead. Again, thanks to everyone who helped out with this work. Constructive, community-driven collaboration is what makes OSM great. cheers, John [1] https://web.archive.org/web/20060105000147/http://www.openstreetmap.org/ [2] http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68093877, https://vimeo.com/mapbox/review/75978159/984cfdb5af [3] https://lists.openstreetmap.org/pipermail/talk/2013-November/068555.html, https://lists.openstreetmap.org/pipermail/talk/2013-November/068577.html, https://lists.openstreetmap.org/pipermail/talk/2013-July/067564.html, https://lists.openstreetmap.org/pipermail/talk/2013-July/067595.html, https://lists.openstreetmap.org/pipermail/talk/2013-July/067730.html [4]
Re: [OSM-talk] Upcoming website features
Thanks everyone for the feedback on the redesign effort. Development work on the redesign is in a lull right now due to competing priorities, but we hope to get back to it and continue refining the design in the near future, and we'll be taking your comments here and on the pull request into account. Also, thanks to Paul for the status updates -- I think they're an effective way to keep interested people in the loop. John ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org - some numbers
Hi Andy, Thanks, this is great. I love having real numbers to discuss. On Tue, Aug 20, 2013 at 4:36 AM, SomeoneElse li...@mail.atownsend.org.ukwrote: Frederik Ramm wrote: Hi, it has been proposed to make the newly released iD v1.1 the default editor on openstreetmap.org, meaning that if someone doesn't explicitly chose an editor they will open iD instead of Potlatch. In an attempt to put some numbers to to the errors made by new mappers debate, I've done a count-back of new users and editors that they use for they area that I keep an eye on in the UK (England and bits of Wales, not including bits that I'm unfamiliar with such as London and the south-east) During the last month in this area: P2 iD JOSM Other (Wheelmap / Go Map! / POI+) Made no newbie errors34 17 3 3 Made at least one newbie error 40 16 1 3 Made more serious errors 5 0 1 0 So 45 of 79 new contributors (57%) made errors with P2, 16 of 33 (48%) with iD, 2 of 5 (40%) with JOSM, and 3 of 6 (50%) with other editors. While there's no doubt a fair margin of error here, what I conclude from this is while it's still much too easy for new contributors to make mistakes with our current editors, there's some indication that they make fewer errors (especially serious ones) with iD than with P2. If you have time, I would love to see more numbers in the future or changeset examples that show what types of errors are most common. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
On Mon, Aug 19, 2013 at 6:01 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: with that approach (letting the users incidentally damage turn restrictions or other relations without warning by deleting members or combining them in a harmful way ) new users will get even more anxious as they will get mailed by others afterwards. Well, we could try sending them polite emails, welcoming them to the community, expressing appreciations for their contributions, and constructively suggesting how to improve their future edits. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
On Mon, Aug 19, 2013 at 12:07 PM, Frederik Ramm frede...@remote.org wrote: It has been claimed often that iD damages relations. Can we somehow substantiate that claim? Could anyone provide a detailed description of a non-esoteric use case that involves * a kind (and structure) of relation that is very common and thus likely to be encountered by a new contributor; * a simple-looking edit that is likely to be made by a new contributor and that results in a broken relation in iD? In what way will the relation be broken, and what indication (if any) does iD display about the problem? The two examples that are most commonly given are deleting then re-drawing (rather than adjusting in place) a section of road that is a member of a route relation, and merging or splitting ways in that are members of a turn restriction. Of these two, the first is more likely to meet your criteria, route relations being much more common than turn restrictions, and merging ways being somewhat uncommon of an action for a new contributor. I haven't actually seen changesets that exhibit either of these cases, however. I don't have any empirical data to back it up, but my hunch is that they occur significantly less frequently than one would expect given the level of concern over them. Comparing iD to P2: * P2 displays colored strokes for ways that are members of route relations; iD does not. We plan to implement this eventually for iD, but until then one could argue that this makes route relations slightly more visible in P2. * But on the other hand, relation memberships are only displayed in the advanced tab of the P2 sidebar, whereas they are always visible in iD. * Neither editor has a warning when you delete a way that is a member of a route relation. * Neither editor has a warning when you merge a way that is a member of a turn restriction. * iD displays modified relations in the save UI. P2 does not. * iD just does the right thinghttps://github.com/systemed/iD/blob/e631faa185358b8b85732d46f1734881342dc4e1/test/spec/actions/split.js#L401-L496when you split ways that are members of a turn restriction. P2 does not. I think that overall, users will be less likely to accidentally damage relations with iD than with P2. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New welcome page
Hi Martin, On Sun, Aug 18, 2013 at 6:18 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Could we extend the basic terms on the new welcome page? The new users I talk to tell me that the number one reason they were hesitant to start contributing to OSM was that it presented itself as complex, highly technical, and easy to mess up. If we want to attract a wider and more diverse set of contributors, we need to make a better first impression -- that's the motivation for the welcome page. Accordingly, it is intentionally communicates only the absolute essentials, values familiar concepts over strict technical precision, and delegates (or will delegate, with this pull requesthttps://github.com/openstreetmap/openstreetmap-website/pull/456) the next step to other resources such as LearnOSM or the iD walkthrough. So I'm going to resist suggestions of the form could we extend the welcome page with X and shouldn't we mention that Y unless there's a strong argument to be made that such additions are absolutely essential. With regards to linking to the wiki, the pull request I linked above adds a new jumping off page for help resources, including the wiki, and updates the welcome page to link to that. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
On Sat, Aug 17, 2013 at 3:50 PM, Bryce Nesbitt bry...@obviously.com wrote: But perhaps most critically of all, before iD becomes the default, are the issues of damaging relations and oneway=yes tagged ways: https://github.com/systemed/iD/issues/1461 https://github.com/systemed/iD/issues/299 iD 1.1 displays relationship memberships in the sidebar much like P2 does. We plan to add additional functionality (e.g. highlighting routes on the map, visual rendering of turn restrictions) in future versions, but feel that 1.1 makes relations visible enough to sufficiently address the concern of unintentional damage. As has been discussed before, we are not planning to add intrusive Are you sure? warnings to iD. Such second-guessing disrupts legitimate workflows and turns away new users, who typically already feel anxiety about doing something wrong. With regards to way reversal, as outlined in the issue you linked, we believe iD's behavior is correct and optimal. If you have a specific concern that hasn't been discussed, please raise it on the issue tracker. Otherwise, again, let's avoid rehashing the previous discussion. Thanks, John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
On Fri, Aug 16, 2013 at 7:02 AM, Frederik Ramm frede...@remote.org wrote: P2 will be available by simply clicking the down arrow next to Edit. Given that Potlatch 1 is still available three years after the introduction of Potlatch 2, I should assume that Potlatch 2 will remain with us for some time yet. Correct. You can also set a personal default on your user settings page, so that clicking Edit will always launch your preferred editor, regardless of the outcome of this discussion. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Using iD
Hi Arnie,
If all you want to do is display your own tiles as a background layer in
iD, you can use one of the existing deployments (openstreetmap.org,
openstreetmap.us/iD/release/) and use the Custom background option, or a
custom background parameter as described
herehttps://github.com/systemed/iD/blob/master/API.md#url-parameters
(examplehttp://openstreetmap.us/iD/release/#background=custom:http://a.tiles.mapbox.com/v3/jfire.map-q93ht09j/{z}/{x}/{y}.pngmap=20.00/-77.02271/38.90085
).
If you want your own deployment of iD with your tiles baked in as preset
background layer, you'll need to clone the repository and edit the
imagery.json https://github.com/systemed/iD/blob/master/data/imagery.jsonfile.
John
On Fri, Aug 16, 2013 at 11:13 AM, Arnie Shore asho...@verizon.net wrote:
All, I'm sure it's out there someplace, but I've failed to find anything
to help me download/install/use iD with my own tile server. (Which
contains a subset of OSM tiles.)
Any urls/help is appreciated big-time.
__**_
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] In the works: iD 1.1
Update: I've opened a pull request, and Tom Hughes has made 1.1.0rc1 available on an OSM.org test server: https://github.com/openstreetmap/openstreetmap-website/pull/424 http://tomh.apis.dev.openstreetmap.org/ Unless any show-stopping bugs are found, I'll release 1.1 in a few days. On Wed, Jul 31, 2013 at 10:45 AM, John Firebaugh john.fireba...@gmail.comwrote: Hi folks, Continuing the experiment that Paul Norman kicked off with announcing proposed and in progress development, I'd like to announce that iD 1.1 is nearing release. I've just tagged 1.1.0rc1, and you can give it a spin here: http://openstreetmap.us/iD/release/ This release focuses on relation editing support and performance improvements. The relations that each feature is a member of are displayed in the sidebar, and when a relation itself is selected, it's members are displayed. You can also search for relations via a new search interface, add and remove memberships, and create new relations. We made performance improvements across the board, focusing on load time and editing performance in dense areas. For example, while iD 1.0.1 on Firefox takes 50 seconds to load a dense area like http://www.openstreetmap.org/edit?editor=idlat=49.969975lon=8.837839zoom=16, iD 1.1 loads it in 20 seconds. In some cases, improvements were limited by native browser performance bottlenecks, but we are seeing some progress by browser developers in eliminating these as well. A detailed changelog is available here: https://github.com/systemed/iD/blob/master/CHANGELOG.md As always, the best place for feedback and bug reports is the iD project on GitHub: https://github.com/systemed/iD/ Thanks, John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] In the works: iD 1.1
Hi folks, Continuing the experiment that Paul Norman kicked off with announcing proposed and in progress development, I'd like to announce that iD 1.1 is nearing release. I've just tagged 1.1.0rc1, and you can give it a spin here: http://openstreetmap.us/iD/release/ This release focuses on relation editing support and performance improvements. The relations that each feature is a member of are displayed in the sidebar, and when a relation itself is selected, it's members are displayed. You can also search for relations via a new search interface, add and remove memberships, and create new relations. We made performance improvements across the board, focusing on load time and editing performance in dense areas. For example, while iD 1.0.1 on Firefox takes 50 seconds to load a dense area like http://www.openstreetmap.org/edit?editor=idlat=49.969975lon=8.837839zoom=16, iD 1.1 loads it in 20 seconds. In some cases, improvements were limited by native browser performance bottlenecks, but we are seeing some progress by browser developers in eliminating these as well. A detailed changelog is available here: https://github.com/systemed/iD/blob/master/CHANGELOG.md As always, the best place for feedback and bug reports is the iD project on GitHub: https://github.com/systemed/iD/ Thanks, John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] comments on new map widget on main page
On Sun, Jul 28, 2013 at 4:26 PM, Greg Troxel g...@ir.bbn.com wrote: I'd like to see two things different; both of these are regressions from the old way and I think easy to address I believe that persisting the location and zoom in the URL hash will address both of these concerns. Please try it out: http://hash.apis.dev.openstreetmap.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Double-clicking on OSM map does not centre the map
The rationale for making the change in Leaflet is to make it so that you can zoom in several levels on a given point without needing to reposition your cursor at each zoom level. For that reason, I prefer the new behavior. Included in the next set of changes to the map UI is the ability to add a marker to the permalink. It will be positionable via dragging. No URL editing required: http://mapui.apis.dev.openstreetmap.org/ On Sun, Jul 21, 2013 at 9:00 PM, Tom MacWright t...@macwright.org wrote: The relevant change in Leaflet: https://github.com/Leaflet/Leaflet/pull/1582?source=cc - the new behavior matches all other map sites and frameworks I can think of, with the exception of Bing. You can replicate the old behavior by clicking the map and dragging it to change the center. There's no easy way to 'get the old behavior back' without doing a core patch to Leaflet, and given that this is the expected behavior with a clear 'other way to do it', I personally don't think it's a high priority to change. On Sun, Jul 21, 2013 at 11:26 PM, Clay Smalley claysmal...@gmail.comwrote: I've noticed the same issue. I liked having an easy way to center the map. Is anyone averse to having this changed back? On Jul 21, 2013 8:02 PM, Andrew Errington erringt...@gmail.com wrote: It used to be that if you double-clicked on the map it would re-centre on the clicked point and zoom in by one level. Now it doesn't. It zooms in, but doesn't re-centre the map. When did this behaviour change? Is it desirable? I don't like it because now I can't centre the map (by double-clicking) and make a markerlink (by editing the permalink lat/lon to mlat/mlon). Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Using OpenStreetMap on a daily basis
On Thu, Jul 11, 2013 at 12:25 AM, Frederik Ramm frede...@remote.org wrote: Have you seen the new map UI proposed by the Mapbox team ( http://mapui.apis.dev.**openstreetmap.org/http://mapui.apis.dev.openstreetmap.org/)? If something along those lines were used, then there would be more than enough room for a markerlink in the share panel. Yes, that's exactly where I'm going with it. Preview: https://f.cloud.github.com/assets/98601/778982/12bfaae4-e9c1-11e2-8afa-826d25c371cb.png ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] OpenLegend (SOTM Sprint Proposal)
Hi Bryce, I can help you with iD presets -- they live here: https://github.com/systemed/iD/tree/master/data/presets I encourage you to use a JSON format rather than XML. It'll be easier for web-based services to consume. John On Tue, Jun 11, 2013 at 8:58 AM, Bryce Nesbitt bry...@obviously.com wrote: For today's San Francisco SOTM Sprint, I'm writing to propose a design effort to bring together legends. The goal is to inspect each major map and build a legend, then combine those legends into a big cheat sheet. Then, inspect each editor and list the features it has presets for. The design effort would likely create an XML schema to represent the legend/presets for a particular design/editor. One future benefit is a mapper who's mapped a particular feature (say, cell phone towers) can see which map their results will go it. It could reduce pressure to make Mapnik do everything. It is also a good sprinty topic, in that it needs someone familiar with each target codebase. Game on? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Who interprets semicolon in tag values?
iD interprets semicolon-delimited tag values specially for purposes of merging tags, for example when joining two adjacent streets. It splits on semicolon and optional whitespace, and then takes the union of the resulting sets of values: https://github.com/systemed/iD/blob/f02df04102e8da4561e66fa7887e9683d582c222/test/spec/core/entity.js#L100-L120 On Fri, May 31, 2013 at 8:03 AM, Jochen Topf joc...@remote.org wrote: Hi! We have had an informal convention for a long time to use a semicolon (;) in tag values to separate multiple values, for instance ref=I 70; US 40 to denote that there are two numbered roads on a way. But most software out there doesn't actually interpret this in any special way. If you know of any software that actually does interpret this specially, please tell me. I am trying to get an idea where and how this is used in the real world. You can answer here on the list or write to me privately, I'll summarize for the list later. Thanks! Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD, relevant tag suggestions
On Sat, May 18, 2013 at 8:50 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: There are some minor issues with what appears as tag suggestions on objects. E.g. I edited a (already quite detailed) hotel and the suggested tags were elevation, wikipedia, note and wheelchair. I think very few hotels have an elevation tagged, ele is generally a complicated thing to tag (you have to understand the relevant reference system(s) to get it right, and the most interesting information in conjunction with a building is obtained only in combination with height) so I'd suggest to remove ele in this case in favor of other more useful tags (e.g. stars / award:hotelstars, email, internet_access, ...). iD's presets system has two levels of suggested tags. The more prominent is that certain tags will, by default, provide visible input fields on certain features, even if the feature doesn't currently have that tag. For hotel, those tags are operator, building, and the various tags that make up the address form. The less prominent level, and presumably what you are referring to, is that iD provides a way to show any tag that is designated as universal, i.e. applicable to all or nearly all features. The UI for this is a set of icons at the bottom of the fields: https://f.cloud.github.com/assets/98601/521827/90e75992-bfd9-11e2-8d64-c45c4696d060.png iD will hopefully eventually have a much larger set of custom fields, so at some point it will probably need to switch from this icon based UI to one based on search: https://github.com/systemed/iD/issues/1070 Your points about the most relevant tags for hotels are good ones. iD's preset system is designed to be highly customizable, and we encourage people to help build out the presets. You don't have to have a programming background to do so. https://github.com/systemed/iD/blob/master/data/presets/README.md cheers, John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD Editor live on OpenStreetMap
On Sun, May 12, 2013 at 8:53 AM, Dave F. dave...@madasafish.com wrote: On 08/05/2013 14:37, Douglas Musaazi wrote: Great work!! let's go ahead and use it. I'd love to but it's very sluggish while dragging in latest FF, the walk-through help keeps hanging the pop-ups appear over the area I want to edit I'm working on performance right now, and the popup menu is a known usability problem. Can you provide more details about the walkthrough problem, or open an issue on https://github.com/systemed/iD/issues? Has an on-line help page been written yet? There is on-line help built in -- click the help icon on the left, or use the 'h' hotkey. How do I unstitch a line segment by segment? In P2 it's done by selecting the end node pressing the Delete key. Yes, this is an open feature request ( https://github.com/systemed/iD/issues/1457). Another way to do it currently is hold Shift and drag-select the nodes you want to delete. In a similar vein how can I add a segment to an existing line? Enter line draw mode, click on the end of the line, continue drawing. You're not the first person to ask about this, so we're thinking of adding a Continue line action to the popup menu. Thanks for the feedback! John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Examples Gov using OSM
On Tue, Mar 26, 2013 at 10:01 AM, Richard Welty rwe...@averillpark.net wrote: i was under the impression that the Code For America folks had done a bunch of work with local governments on stuff that used OSM as a basemap. Nick Doiron and Jessica Lord were Code for America fellows last year and presented at SotM PDX. How Code for America Makes Maps http://www.slideshare.net/NicholasDoiron/how-code-for-america-makes-maps-14754312 Transit maps for Macon, Georgia https://github.com/codeforamerica/Transit-Map-in-TileMill http://www.mta-mac.com/map.html ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US-Canada Border between BC and Washington State
On Mon, Sep 17, 2012 at 4:48 PM, Clifford Snow cliff...@snowandsnow.uswrote: I've been doing some work in the North Cascades National Park. It appears that the border between the US and Canada is wrong. Look at http://www.openstreetmap.org/?lat=48.9841lon=-121.743zoom=13layers=M It appears that the boarder sags to the south. I see tags man_made = survey_point which would indicate that the border placement is correct. Can anyone recommend how to validate the border placement? It appears to be correct. If you zoom in on the Bing imagery, you can see that the border coincides with a strip of land that has been cleared of vegetation: the border vista. If you wanted to further validate it, you could check that the survey points match those published by the Boundary Commission: http://www.internationalboundarycommission.org/coordinates/49thParallel.htm The border does not follow the 49th parallel exactly: http://opinionator.blogs.nytimes.com/2011/11/28/a-not-so-straight-story/ Clearly, some of the other boundaries in the area (e.g. the Mt. Baker - Snoqualmie National Forest multipolygon) are incorrect and should be sharing the same way. John ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
