Re: [OSM-dev] Matching live bus position to route?
Hey Grant, Look into wmata-gtfsrealtime: https://github.com/kurtraschke/wmata-gtfsrealtime which aims to solve the same problem for DC. It's semi-impenetrable Java code but the jist is that you create a 'unit space' (fancy word for distances in a bunch of dimensions) and use it to calculate nearest-neighbor from real life bus to theoretical routed bus. Tom On Tue, Oct 22, 2013 at 10:13 AM, Grant Slater openstreet...@firefishy.comwrote: Hi OSM-Dev, Dev challenge... I have a near live feed of bus positions for around 130 buses and (soon) all the passenger bus routes. Routes are relations in OSM. Does anyone have experience or firm suggestions on how best to match a live feed of bus positions to a set route? Feed Data: * BusID (no direct match to route) * Timestamp * Position * Travel Direction (Degrees) I also have 2 weeks worth of historical data. Typically: * Bus A will drive from depot to start of route 1 and loop on route 1 all day... maybe route 4 tomorrow. * Bus B as above but does route 2 and then route 3... * Bus C will be deployed on any route as required. All routes may share a few short segments. Kind regards Grant ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Making iD the default editor on osm.org
As good a time as ever to remind everyone that we'd love your help on the iD project. Head over to the GitHub repository: https://github.com/systemed/iD Choose an issue, and go for it! You will be part of making this actually happen. Thanks, Tom On Mon, Aug 19, 2013 at 5:27 PM, NopMap ekkeh...@gmx.de wrote: Hi! I have just worked through all the previous posts here and experimented with the test instance in my home turf. The short anwer is: No, I do not believe that ID is in a state to make it the default editor, especially not to welcome newbies. The long answer: I still see very bad performance in Firefox. I noticed that editing has been limited to zoom 16 and higher which is a very crude way to limit the data displayed. But it also makes orientation very difficult when you have to move around. Even when there are not many lines to display, ID remains jumpy, dragging of the map rather results in two jumps for moving a full screen with up to one second delay in denser areas. I agree with the previous posts that ID is not a suitable editor for beginners/as default as long as it presents destructive operations in such a prominent manner. I'm referring to the delete button but also to the make-square, make-round and rotate options. You do not need these to draw streets on top of tracks or aerial imagery, which is the basic start of mapping. I have never used them at all. But they can be very destructive for existing geometry. An expert mode where you can add those operations later might be a good solution. I tried deleting a few things and there was no warning that I was acting destructively. The warning before saving is too general and the list of change objects also does not indicate whether I did something dangerous. I believe that immediate warnings when you do something dangerous (and an expert switch to disable them later) would be very helpful to prevent damage and teach the user how to proceed. What's more, the existing icons would confuse me as a newcomer. For ways, there is a move-around icon (which is useful), if I click on a node, only delete is shown, nothing else. In particular, there is no move-around icon. As a powermapper I know that I can directly drag the node and don't need it, but to a newcomer the absence might suggest that you should rather delete the node with the prominent trashcan and re-create it somewhere else. The wording on the delete button is also misleading. It says: remove this from the map. But that is not what it does. It deletes it from the database, not from any particular map. This encourages the common misunderstanding that OSM is a map and of course unnecessary deletions. On the other hand, some very useful functions seem to be missing. Or at least they are not offered as icons and I couldn't figure out how to do it. One is click on end node of line and continue drawing it (click on node in P2). Another is copy tags from similar way (r in P2). There is some relation handling, but the visibility of relations is still insufficient. They are shown in the sidebar, but with all instances I tried, the normal tags took up all the visible space in the bar and you had do scroll down to read anything about relations. As they are not marked on the map in any way, they are still invisible to the unsuspecting user. If you don't know that there must be a relation there and directly look for it, they remain totally invisible. I found the handling of multipolygons very confusing. I clicked a MP area and the sidebar showed Multipolygon. Pretending that I didn't know what that is I clicked i, only to be rewarded with there is no documentation for this key. I deleted some of the members with the message not downloaded and ID accepted that without warning. I see no way a newcomer had any chance to use this. I agree with the previous posts that OSM should not create a connection to Facebook, Twitter or any other social service without conscious choice by the user or in a way that suggests that it is an integral part of OSM or that membership there is required in any way. A good solution might be a plain share link on the save page that leads you to a setting where you can opt-in to your favorite services if you like to. Or maybe you could detect the Facebook session and tracking cookies and show it the button only if you have an active session. But currently it looks like OSM is simply advertising for Facebook. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Making-iD-the-default-editor-on-osm-org-tp5773770p5774123.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using iD in tablet
Touch-related tasks are tagged 'touch' in the issue tracker: https://github.com/systemed/iD/issues?labels=touchpage=1state=open Mainly, support on mobile touch devices like iOS and Android devices will be a significant challenge because of their weak processors incomplete browser implementations. On Sun, Aug 18, 2013 at 8:14 AM, amrit karmacharya amrit...@gmail.comwrote: I tried to use iD in Lenovo IdeaTab. Firstly i had difficulty in clicking the iD editor option, most of the time it tried to open potlatch. When it finally loaded, the screen was not enough. I only got the upper left part. I read it http://www.theverge.com/2013/5/7/4306500/openstreetmap-id-editor-from-mapbox-launches that it will usable on tablet. I'd like to know how can i track the progress of the mobile version? ___ 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] The new link on the OSM map
Is it really a terrible weight to update JOSM to recognize the new format? Given that JOSM is on version 6,115 and this is essentially a 'changing a regex' type situation. Can we stop calling any feature that changes the behavior of the site a major step backwards? Yes, things are different and possibly some use case you had is different or harder, but realize on the other side this is (1) generally a beneficial change and (2) the result of a volunteer already slogging through tens or hundreds of comments on a GitHub queue and finally getting it through. And, finally, it's merged... and the first thing we hear is negative criticism about a corner case that says you did a bad thing entirely. This is why nobody wants to code on openstreetmap-website. On Thu, Aug 8, 2013 at 3:36 AM, Peter Wendorff wendo...@uni-paderborn.dewrote: Hi Maarten, the benefit with the new link format, where position and layers are constantly stored in the part after the hash (#) is that browsers don't need or assume to need a reload. If you change the address (before the #) completely, a reload of the page is necessary, that was the case up to the change. Now it's not necessary to reload the page to get the correct link in the address bar. What you complain is of course an argument straight in the opposite direction, but both ways are perfectly valid. You are in fact right that it's not possible any more to determine from the link which part of the coordinate is latitude and which is longitude, but it's consistently the same any time, so that's not that big problem either. Probably the hash format could better be extended by lat/lon to be something like #z=15/lat=51.2/lon=8.7 Your complaint about reloading the page to get the initial view back is IMHO an unusual one as it assumes that you go to the page with a direct link to a defined position; something which is possible with osm.org, but something nobody cared about in the last days probably. For this wish I don't have a solution combining your demand with the benefits of the new hash-format, but probably even there is a solution possible. regards Peter Am 08.08.2013 09:16, schrieb Maarten Deen: On 2013-08-08 09:08, Maarten Deen wrote: Very nice that the main map now shows a link as standard, but why does the format have to be changed? Now JOSM needs to be changed because it does not recognise this type of link. What was wrong with the old lat= and lon= style? From this link I can not see what the latitude and longitude is. I have to know in which order it is. I'm sorry, but IMHO this is yet another step backward. Added complaint: before, I could zoom in, move the map, do whatever I wanted and then reload the screen and I got the initial view back. Now the map link changes when you zoom or move the map, making it difficult to get the initial view back. You have to remember to copy the link and than paste it back again otherwise you will never get the initial view. Please get the old style link and working back. The fact that there is no direct visible link to the map is now the least of the problems. Regards, Maarten ___ dev mailing list dev@openstreetmap.org http://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] The new link on the OSM map
It is not just about JOSM, the change breaks *every application, web service or browser plugin* that creates a reference to the osm main page or that could parse an OSM url. Links to the homepage are backwards-compatible. We've set up redirects. No. If you just go ahead with changes that break things, you should anticipate damage reports. Bug reports are fine, and expected. I'm not asking for silence: I'm asking for less editorializing, hyperbole, and negativity. On Thu, Aug 8, 2013 at 10:33 AM, NopMap ekkeh...@gmx.de wrote: tmcw wrote Is it really a terrible weight to update JOSM to recognize the new format? It is not just about JOSM, the change breaks *every application, web service or browser plugin* that creates a reference to the osm main page or that could parse an OSM url. That's a little bit more :-). What's more as this was done unannounced (no, an internal issue tracker is not an announcement), all these applications are failing now as a surprise for their users. tmcw wrote Can we stop calling any feature that changes the behavior of the site a major step backwards? No. If you just go ahead with changes that break things, you should anticipate damage reports. Maybe a wider discussion of the expected impacts could have avoided the problem, but asking for silence on the topic will neither fix the problem nor the (lack of) procedure which created it. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/The-new-link-on-the-OSM-map-tp5772913p5772979.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ 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] The new link on the OSM map
And do you know what it is? Somebody puts a request somewhere that they want it changed, some coder implements it and only then the world knows about it and the rest of the world has to change their behaviour because one person wanted it changed. Do-ocracy at work. Please read Paul's message posted before yours. This was announced and discussed both on GitHub and on the talk@ list, before it was launched. On Thu, Aug 8, 2013 at 11:08 AM, Maarten Deen md...@xs4all.nl wrote: On 2013-08-08 14:49, Tom MacWright wrote: Is it really a terrible weight to update JOSM to recognize the new format? Given that JOSM is on version 6,115 and this is essentially a 'changing a regex' type situation. Is that a reason to do it? Because other changes are not hard? What _is_ the reason to change it to this format? Is there a reason at all? Can we stop calling any feature that changes the behavior of the site a major step backwards? Yes, things are different and possibly some use case you had is different or harder, but realize on the other side this is (1) generally a beneficial change and (2) the result of a volunteer already slogging through tens or hundreds of comments on a GitHub queue and finally getting it through. And, finally, it's merged... and the first thing we hear is negative criticism about a corner case that says you did a bad thing entirely. This is why nobody wants to code on openstreetmap-website. Sure, I understand that it may not be welcome to critise changes that somebody worked hard on, but what do you expect, that everything that is done is Good and Proper and you rather not hear critisism? What planet are you on? And do you know what it is? Somebody puts a request somewhere that they want it changed, some coder implements it and only then the world knows about it and the rest of the world has to change their behaviour because one person wanted it changed. Do-ocracy at work. I never before heard oh, I would like the URL format changed, or it's better to have the URL geolocation change when you move the map. That last one was only vaguely mentioned when it came to light that the permalink generation was changed. And even then I didn't see the consequence. Basically: there is no permalink anymore. There is an export link but no permalink. Someone changed the whole meaning of the thing. What I said before: perfectly good functionality has been removed. And I do not see the step forward in that. Regards, Maarten On Thu, Aug 8, 2013 at 3:36 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: Hi Maarten, the benefit with the new link format, where position and layers are constantly stored in the part after the hash (#) is that browsers don't need or assume to need a reload. If you change the address (before the #) completely, a reload of the page is necessary, that was the case up to the change. Now it's not necessary to reload the page to get the correct link in the address bar. What you complain is of course an argument straight in the opposite direction, but both ways are perfectly valid. You are in fact right that it's not possible any more to determine from the link which part of the coordinate is latitude and which is longitude, but it's consistently the same any time, so that's not that big problem either. Probably the hash format could better be extended by lat/lon to be something like #z=15/lat=51.2/lon=8.7 Your complaint about reloading the page to get the initial view back is IMHO an unusual one as it assumes that you go to the page with a direct link to a defined position; something which is possible with osm.org [1], but something nobody cared about in the last days probably. For this wish I don't have a solution combining your demand with the benefits of the new hash-format, but probably even there is a solution possible. regards Peter Am 08.08.2013 09:16, schrieb Maarten Deen: On 2013-08-08 09:08, Maarten Deen wrote: Very nice that the main map now shows a link as standard, but why does the format have to be changed? Now JOSM needs to be changed because it does not recognise this type of link. What was wrong with the old lat= and lon= style? From this link I can not see what the latitude and longitude is. I have to know in which order it is. I'm sorry, but IMHO this is yet another step backward. Added complaint: before, I could zoom in, move the map, do whatever I wanted and then reload the screen and I got the initial view back. Now the map link changes when you zoom or move the map, making it difficult to get the initial view back. You have to remember to copy the link and than paste it back again otherwise you will never get the initial view. Please get the old style link and working back. The fact that there is no direct visible link to the map is now the least of the problems. Regards, Maarten __**_ dev mailing list dev@openstreetmap.org
Re: [OSM-dev] The new link on the OSM map
Tom's hyperbole that I claim you did a bad thing entirely I was referring to: I'm sorry, but IMHO this is yet another step backward. 'Yet another step backward', outside of the expression two steps forward, another step back means 'a bad thing in general' in common usage. Perhaps you were implying 'two steps forward' and that was lost to everyone. Sorry for that. I merely point out the flaws I see. You did on the JOSM tracker: the ticket you posted ( http://josm.openstreetmap.de/ticket/8945 ) was polite, straightforward, and to the point. If you had posted the same thing here, this would have been a more productive dialog. On Thu, Aug 8, 2013 at 1:11 PM, Frederik Ramm frede...@remote.org wrote: HI, On 08/08/13 19:02, Peter Wendorff wrote: The ticket was there already, I added a patch now Thanks. I have applied the patch and closed the ticket. Tonight's josm-latest will then support the new URL scheme, and we can all happily live on the same planet again. 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/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TileStache license
Just check the GitHub repo's LICENSE.txt - https://github.com/migurski/TileStache/blob/master/LICENSE - looks like 3-Clause BSD On Sun, Jun 2, 2013 at 4:10 PM, Vince Berubey scream...@hotmail.com wrote: Hi, I'm using TileStache. I cannot find anywhere if TileStache is restricted by a license? I would assume GNU LESSER GENERAL PUBLIC LICENSE but I cannot find anything. Does anybody have information about it? Thanks. ___ 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] What about Windows 8?
Browsing the map should work fine. iD isn't touch-compatible yet, but will be - tracked in the following tickets: * https://github.com/systemed/iD/issues/1431 * https://github.com/systemed/iD/issues/151 * https://github.com/systemed/iD/issues/607 On Thu, May 9, 2013 at 3:58 PM, Vince Berubey scream...@hotmail.com wrote: Hi, Has anyone tried to use OpenStreetMap on a Windows 8 tablet? Is the multitouch feature working fine, zoom-in/zoom-out? Thank you ___ 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] Where do you find out about ID?
Hi Nop, By virtue of being new, iD doesn't have quite as much docs for different use cases as Potlatch 2 or similar. But there are a few resources to get started with: * http://mapbox.com/osmdev/ (dev blog w/ series of posts about architecture) * https://github.com/systemed/iD/blob/master/ARCHITECTURE.md (architecture readme) * https://github.com/systemed/iD/blob/master/CONTRIBUTING.md (readme for different sorts of contributing) * https://github.com/systemed/iD/issues?state=open (issue tracker) We'd like to just use #osm-dev for any discussion of the editor, and use the issue tracker (as linked) for any and all technical discussion, bugs, and feature development. As far as documentation for _using_ the editor, there's help documentation embedded in it as well as an intro tour for new users. Tom On Fri, May 3, 2013 at 5:29 PM, NopMap ekkeh...@gmx.de wrote: Hi! Tonight a very stupid question. I got interested in the new ID editor and I've been trying to find out more about it, but without success. Potlatch2 has a wiki page with getting started info, how to set it up, customize etc. and a mailing list. JOSM has its own Wiki with technical stuff and also a mailing list. But for ID I cannot find any similar information, just a few announcements that it exists. The wiki holds no technical information and the link project introduction just points to a demo instance of the editor, no background info whatsoever. There also seems to be no mailing list where you could ask those questions, at least not in the OSM list. Is there really no such stuff or is it just hard to find? bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Where-do-you-find-out-about-ID-tp5759537.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ 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] Add an iD link to the Potlatch no-Flash screen
This should be conversation over whether we should link to iD or embed it, not a derail into opinions and feature requests. As far as linking to iD: I think we should focus on the pull request to include iD on the site https://github.com/openstreetmap/openstreetmap-website/pull/225 rather than linking to it in the short-term. The pull request is very close to being complete. Kimaido: the presence/absence of an 'advanced mode' has been discussed at length in the iD tracker * https://github.com/systemed/iD/issues/759 * https://github.com/systemed/iD/issues/1181 * https://github.com/systemed/iD/issues/1278 In short, we would rather have one UI that works decently for everyone rather than splintering it into 'easy' and 'advanced' modes. For super-advanced editing, there will always be JOSM. iD does handle relations, though it does not support a relations editing UI at the moment: search for 'relations' in the issue tracker and the commits. There has been a ton of work on the existing relations support, how it interacts with pre-existing relations, and plans for simpler interfaces for editing relations. Yes: iD has room to grow. But I don't think that the 'a front page editor must include X feature that I think is important' is a useful criteria. If you ask whether an editor has been tested, used, deployed, and generally regarded as safe, iD fits that goal. Tom On Mon, Apr 22, 2013 at 10:13 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/4/22 kimaidou kimai...@gmail.com Hi all I am following this discussion about ID. I think I won't use ID but keep Potlach as long as ID does not integrate an advanced view for power users. I use Potlach a lot to do some quick additions, and I always use preselections then switch to the advanced tab to control which tags/values are used and to add some specific tags. I have probably missed the same feature in ID ? +1, a full editor promoted on the main page as one of the principal editors should IMHO display the tags and not just an interpretation of them. Also it seems as if iD doesn't handle relations yet, at least it seems to have problems in recognizing multipolygon relations. cheers, Martin ___ 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] Add an iD link to the Potlatch no-Flash screen
Hi Martin, it seems as if doesn't expose way membership to the user currently. In any area with multipolygons or turn restrictions or, likely more difficult to fix, other types or relations, mappers will really break a lot without even being able to notice. It doesn't expose relations in the UI, but does not break them and makes the same relatively smart choices as P2 when users make operations on ways and nodes in relations. break a lot is unfounded and untrue: users have been testing iD for weeks now and we are not seeing significant problems from this approach. +1 in case of feature X, but freeform tagging is one of the key features that really make osm what it is What's the assertion here, that iD doesn't support freeform tagging? That's entirely incorrect: read the issues and look at the user interface. iD supports freeform tagging: just click 'other' and use the tags UI if you don't want to use presets. Tom On Mon, Apr 22, 2013 at 10:45 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: On 22/apr/2013, at 16:25, Tom MacWright t...@macwright.org wrote: For super-advanced editing, there will always be JOSM. iD does handle relations, though it does not support a relations editing UI at the moment: search for 'relations' in the issue tracker and the commits. There has been a ton of work on the existing relations support, how it interacts with pre-existing relations, and plans for simpler interfaces for editing relations. it seems as if doesn't expose way membership to the user currently. In any area with multipolygons or turn restrictions or, likely more difficult to fix, other types or relations, mappers will really break a lot without even being able to notice. Yes: iD has room to grow. But I don't think that the 'a front page editor must include X feature that I think is important' is a useful criteria. If you ask whether an editor has been tested, used, deployed, and generally regarded as safe, iD fits that goal. +1 in case of feature X, but freeform tagging is one of the key features that really make osm what it is Cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Add an iD link to the Potlatch no-Flash screen
Hi Peter, Please read the previous posts and the linked tickets. Here's the one for you: https://github.com/systemed/iD/issues/1181 On Mon, Apr 22, 2013 at 11:30 AM, Peter Wendorff wendo...@uni-paderborn.dewrote: Hi. As far as I see it's entirely possible to add free tags (there's an expand link/button that shows other tags). But IMHO it's not enough, because that only shows tags that are not included elsewhere in the presetted tag stuff. The problem with this is, that for the presetted stuff it's (or at least seems to be) impossible to get the raw tags out of it, preventing to learn them (yes, novice mappers should not have to, but IMHO they should be able to understand the raw tags). So this tag list should IMHO show all tags, not only those not exposed already by even more human readable UI translations. regards Peter Am 22.04.2013 16:50, schrieb Tom MacWright: Hi Martin, it seems as if doesn't expose way membership to the user currently. In any area with multipolygons or turn restrictions or, likely more difficult to fix, other types or relations, mappers will really break a lot without even being able to notice. It doesn't expose relations in the UI, but does not break them and makes the same relatively smart choices as P2 when users make operations on ways and nodes in relations. break a lot is unfounded and untrue: users have been testing iD for weeks now and we are not seeing significant problems from this approach. +1 in case of feature X, but freeform tagging is one of the key features that really make osm what it is What's the assertion here, that iD doesn't support freeform tagging? That's entirely incorrect: read the issues and look at the user interface. iD supports freeform tagging: just click 'other' and use the tags UI if you don't want to use presets. Tom On Mon, Apr 22, 2013 at 10:45 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: On 22/apr/2013, at 16:25, Tom MacWright t...@macwright.org wrote: For super-advanced editing, there will always be JOSM. iD does handle relations, though it does not support a relations editing UI at the moment: search for 'relations' in the issue tracker and the commits. There has been a ton of work on the existing relations support, how it interacts with pre-existing relations, and plans for simpler interfaces for editing relations. it seems as if doesn't expose way membership to the user currently. In any area with multipolygons or turn restrictions or, likely more difficult to fix, other types or relations, mappers will really break a lot without even being able to notice. Yes: iD has room to grow. But I don't think that the 'a front page editor must include X feature that I think is important' is a useful criteria. If you ask whether an editor has been tested, used, deployed, and generally regarded as safe, iD fits that goal. +1 in case of feature X, but freeform tagging is one of the key features that really make osm what it is Cheers, Martin ___ dev mailing list dev@openstreetmap.org http://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
[OSM-dev] The Overpass Augmented Changesets API
Hi all, Any Overpass API knowledge-holders who know about augmented_diffs around? So today an experiment by Ian Dees w/ some small hacks by myself got in webmonkey: http://www.webmonkey.com/2013/04/watch-openstreetmap-improve-in-real-time/ Cool! So, I've got a few questions, since the API that this hack relies on, which Ian found in the Achavi project: http://overpass-api.de/achavi/ seems to be entirely undocumented: the Augmented Diffs wiki page ( http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs ) documents the format but not the endpoint, its query strings, and so on. Neither does overpass-api.de (at least nowhere in English) So: questions. What does `info=yes` and `info=no` mean? Does the BBOX argument work, and what argument order does it accept? Are there any other querystring arguments that might be useful - for instance, a limit argument would be wonderful, since right now the API returns 'all items', which is around 3.5MB gzipped per user per minute. Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX Planet Dump
Risking to sound way too negative I have to ask what is the point of creating gpx dumps with the same data content as API queryable data? For the same reason a planet file is published. My use case here is generating a worldwide tile layer of GPX data, and that would not be viable via querying the API - either it would take a very, very long time with individual queries, or the tile service would be reliant on OSM's API staying up. Just as people don't rely on the /map call to generate maps of streets, they shouldn't rely on /gpx to generate maps of tracks. On Sat, Apr 6, 2013 at 10:44 AM, Gregory Williams greg...@gregorywilliams.me.uk wrote: -Original Message- From: Peter Gervai [mailto:grin...@gmail.com] Sent: 06 April 2013 13:50 On Fri, Apr 5, 2013 at 5:37 PM, Ian Dees ian.d...@gmail.com wrote: - This dump only includes the data inserted into the database (lat, lon, Risking to sound way too negative I have to ask what is the point of creating gpx dumps with the same data content as API queryable data? My original request - years ago - came up because I missed additional data contained in the GPX files, especially HDOP values and waypoints. As far as I see this dump will not contain either; basically you dump what anyone could dump by querying the API, you only save the resources for not doing it one-by-one, right? If you followed that argument through then you'd also be able to say that there's no point in publishing the planet file each week, since it's all queryable via the API. The point of publishing all of the GPX data is, just like the planet, when you're doing something on a larger scale than would be sensible, polite, or in line with the usage policy for the API. Gregory ___ 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] [Talk-us] Chicago Hack Weekend
Alex I also just booked flights - excited to go, first time in the windy city. On Tue, Mar 26, 2013 at 10:06 AM, Toby Murray toby.mur...@gmail.com wrote: I booked my flight last night. You should too! Toby On Sat, Mar 23, 2013 at 12:52 PM, Ian Dees ian.d...@gmail.com wrote: Hi list-goers, Knight-Mozilla OpenNews and myself are hosting a hack weekend April 27th and 28th in the heart of downtown Chicago. These sorts of hack weekends are a chance for the OSM developer community to get together and work on projects to improve and grow the software behind OSM. If you don't have anything specific to work on and are well-versed in Rails or JavaScript, Python or Java, there's plenty for you to help with. We'll have food and beverages along with some great socializing after long days of coding or discussing features we'd like to see in OSM. For more detailed information, please visit the wiki page here: http://wiki.openstreetmap.org/w/index.php?title=Chicago_Hack_Weekend_April_2013 -Ian ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] iD editor chat transcript
Hey all, Just finished up a chat about iD in #ideditor to discuss post-alpha0 pre-alpha1 plans. You can check out the log here: http://bl.ocks.org/d/4503558/ For background, here are our posts on iD: http://mapbox.com/osmdev/ and the testing instance: http://geowiki.com/iD/ Thanks everyone for joining, and recent contributors like sabas for reporting issues. The goal with alpha1 is to switch from api06 to osm.org, so please test it out and report any editing issues you can find! Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] CORS on the Wiki
Hey all (and especially Grant Jochen), So, the iD editor has this nice 'reference pane' which shows tag/value summaries from TagInfo, if available. TagInfo also provides thumbnails for these combos in the form File:Foo. Unfortunately that doesn't map to a real URL (by design). There's an API to get at the contents, like http://wiki.openstreetmap.org/w/api.php?action=queryprop=imageinfotitles=Image:Residential.jpgiiprop=url|contentformat=xml But this doesn't support CORS. It doesn't look like MediaWiki supports CORS at this point ( https://gerrit.wikimedia.org/r/#/c/9718/ ), so either we're looking at implementing this on a server-level in Apache, having TagInfo expose actual image URLs, or implementing it in MediaWiki. Any other thoughts here? I obviously am unable to mess with server configuration of wiki.openstreetmap.org, but if, for instance, patching MediaWiki would do the trick, I can probably do that. Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] CORS on the Wiki
Ah, wait! It supports JSONP, I'm a fool: http://wiki.openstreetmap.org/w/api.php?action=queryprop=imageinfotitles=Image:Residential.jpgiiprop=url%7Ccontentformat=jsoncallback=foo On Tue, Jan 8, 2013 at 5:31 PM, Katie Filbert filbe...@gmail.com wrote: On Tue, Jan 8, 2013 at 11:17 PM, Tom MacWright t...@macwright.org wrote: Hey all (and especially Grant Jochen), So, the iD editor has this nice 'reference pane' which shows tag/value summaries from TagInfo, if available. TagInfo also provides thumbnails for these combos in the form File:Foo. Unfortunately that doesn't map to a real URL (by design). There's an API to get at the contents, like http://wiki.openstreetmap.org/w/api.php?action=queryprop=imageinfotitles=Image:Residential.jpgiiprop=url|contentformat=xml But this doesn't support CORS. It doesn't look like MediaWiki supports CORS at this point ( https://gerrit.wikimedia.org/r/#/c/9718/ ), so either we're looking at implementing this on a server-level in Apache, having TagInfo expose actual image URLs, or implementing it in MediaWiki. Any other thoughts here? I obviously am unable to mess with server configuration of wiki.openstreetmap.org, but if, for instance, patching MediaWiki would do the trick, I can probably do that. http://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains ? Cheers, Katie Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Katie Filbert filbe...@gmail.com @filbertkm / @wikimediadc / @wikidata ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] iD Meeting on Thursday
Hi All, This thursday at 11pm EST, we're planning on huddling in the #ideditor channel (on irc.oftc.net) as well as on Skype to talk about where we're at going with the iD editor project. We'll have John, Ansis, Saman, and Alex around and also be on Skype for doing voice. If you're new to the idea of iD, here's a recent post about the alpha0 release: http://mapbox.com/osmdev/2012/12/22/alpha0/ Please join in if you'd like to hear contribute! Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] iD Meeting on Thursday
Hey, Definitely. 11 is our shot at making this work for both Pacific time and London, but it's hard to hit every zone. If you want to drop into #ideditor any other time, we're usually there 9-6EST at least. Tom On Tue, Jan 8, 2013 at 6:44 PM, Svavar Kjarrval sva...@kjarrval.is wrote: Would be nice to participate but I'm not a fan of attending meetings 4 o'clock in the morning (GMT+0). Will there be a chatlog available afterwards? - Svavar Kjarrval On 08/01/13 23:29, Tom MacWright wrote: Hi All, This thursday at 11pm EST, we're planning on huddling in the #ideditor channel (on irc.oftc.net) as well as on Skype to talk about where we're at going with the iD editor project. We'll have John, Ansis, Saman, and Alex around and also be on Skype for doing voice. If you're new to the idea of iD, here's a recent post about the alpha0 release: http://mapbox.com/osmdev/2012/12/22/alpha0/ Please join in if you'd like to hear contribute! Tom ___ 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
[OSM-dev] iD alpha0
Hey all, Happy to announce that early tomorrow we're tagging an alpha0 release of iD for testing development: http://mapbox.com/osmdev/2012/12/22/alpha0/ As you all know, creating an editor is a very big effort and there's still a long way to go. What this mostly means is that we're happy with this set of features being good for an alpha release series, working on stability, and then adding a lot of great stuff (powerful presets) when we enter beta. On a technical level, it also means that development is shifting from our intense-but-enjoyable regime of working in the master branch to working in feature and bugfix branches and trying to keep master in a continually-improving state. And that we are, as much as ever, excited for any new contributors to join. A big thanks to Saman, John, Alex, Richard, Martin and more for their work towards this point. Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Screenshots from OpenStreetMap-Carto spot checking
Hey, Last few days Dane I have been working on optimizing Carto for this case - try out the 'condense' branch: https://github.com/mapbox/carto/tree/condense This requires one small change: in amenity-symbols.mss, change line 82 to [power = 'generator'][[generator:source] = 'wind']::power, Since condense now supports field-field combinations as well as : in field names. Anyway, the main result of this work is that the condense branch (on my machine) brings Carto's processing time from 2.07 seconds to 0.76 seconds, so about 2.5x faster. There's more optimization work that could be done, and this work unfortunately hasn't started to change the XML output to make a more efficient product for Mapnik to process. It's still an experimental branch, but should consitute a Carto 0.9.5 when it hits stability. Tom On Wed, Dec 19, 2012 at 5:04 PM, Alex Barth a...@mapbox.com wrote: Toby / AJ: I just captured your reports on the issue queue: https://github.com/gravitystorm/openstreetmap-carto/issues/26 If anyone else has found issues like these, please report them right away on the GitHub project: https://github.com/gravitystorm/openstreetmap-carto/issues Thanks! On Dec 19, 2012, at 4:18 PM, AJ Ashton aj.ash...@gmail.com wrote: On Wed, Dec 19, 2012 at 3:29 PM, Toby Murray toby.mur...@gmail.com wrote: I was doing some poking around yesterday and noticed that county borders (admin_levl=6) aren't being rendered at zoom 9 and 10. But I do recall some confusion on the existing style between ways and relations. I don't remember the details but there was some difference between the zoom level at which ways and relations tagged with admin_level=6 got rendered. Maybe this caused confusion when porting to carto? Easy place to see this difference: http://bl.ocks.org/d/4271706/#9.00/39.4664/-96.9125 This seems to be about boundary relation way members being individually (and redundantly?) tagged with boundary=administrative. Some of the admin_level=6 ways in this area [1] are tagged as boundary=administrative, and others are tagless members of boundary relations. If you zoom out, the tagless ways disappear at zoom level 10 and below. [1]: http://osm.org/go/T7OwGz3-- This commented out section of the stylesheet may be why the CartoCSS version is different: https://github.com/gravitystorm/openstreetmap-carto/blob/master/admin.mss#L75-L85 -- AJ Ashton ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ 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] Carto-based Mapnik OSM Rendering
Hey, To make it a bit easier to compare, here's the two on a split screen: http://bl.ocks.org/d/4271706/ From a cursory scan, there are some labelling and font changes (mostly for the better, in my opinion) and a possible bug around the coloring of the botanical garden. Tom On Wed, Dec 12, 2012 at 4:03 PM, Ian Dees ian.d...@gmail.com wrote: Hi all, With some help from the MapBox folks I set up a layer on the OSM US server that renders from a recent version of the openstreetmap-carto stylesheet [0] converted to Mapnik XML: http://tile.osm.osuosl.org/tiles/osm_carto/preview.html#15/41.8813/-87.6299 You can compare this with a (semi-old) version that comes from the existing Mapnik XML-based stylesheet the Carto one is based on: http://tile.osm.osuosl.org/tiles/osmus/preview.html#15/41.8813/-87.6299 This server isn't the fastest thing in the world so please don't hammer it to death. Feel free to use it to help improve the carto-based stylesheet though! I'm happy to update the stylesheet at any time. -Ian [0] https://github.com/gravitystorm/openstreetmap-carto ___ 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] Announcing openstreetmap-carto v1.0 (and v2.0!)
Hey Andy, This is really awesome - the Carto looks super-clean and hackable for new coders. Can't wait to see this be used to tackle a lot of the ongoing requests as well as just subtle design improvements. Nice work! On Thu, Dec 6, 2012 at 6:21 AM, Paweł Paprota ppa...@fastmail.fm wrote: Hi Andy, openstreetmap-carto is a project to re-implement the standard OpenStreetMap mapnik style, in CartoCSS[1]. At the OpenStreetMap Hack Weekend in London last Sunday I released v1.0 of project, and went to the pub before telling anyone! This is an amazing effort. For a couple of weeks now I've been wanting to set up a local environment to see this new style and then maybe set something up on the dev server so you can show it off to a larger audience. Hopefully I will finally get some time soon for this. Keep up the great work! Paweł __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
The biggest problem with the Mapnik stylesheet right now is that it's in SVN. Not the technology, but the fact that this gives people without commit access to that repository no clear way to contribute. There is no way to 'just do it' until the style is actually maintained in GitHub, actually welcomes contributions, and has active maintainers. Until then we're just talking. On Tue, Nov 13, 2012 at 5:32 PM, sly (sylvain letuffe) li...@letuffe.orgwrote: Le mardi 13 novembre 2012 23:25:44, Paweł Paprota a écrit : On 11/13/2012 11:13 PM, Derick Rethans wrote: I would rather see as much useful things rendered that make sense for *mappers*. Pretty tiles should also be made, but as far as I know, the default style that is on openstreetmap.org is for *us* - the people who add data. Well, that's the usual question about what is osm.org supposed to be. I share Derick's view, but maybe what we need is someone to just do it and split the problem in two maps. http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist#Backgound_map_with_the_most_possible_objects -- sly (sylvain letuffe) ___ 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] Notes from today's iD huddle on #osm-dev
Definitely. So far iD is taking a few approaches that differ from Potlatch: - Instead of storing undo data in a separate undo stack, we're creating a 'persistent datastucture' style graph that preserves every version of data while trying to keep memory usage low. This means that operations, undo, and (I think) changeset creation can be implemented fairly simply, but things like 'showing the 'elastic band' for drawing ways isn't straightforward, and more important stuff like how to merge in new data downloaded from the API - without having this data removed by undo operations - isn't really solved yet. - Right now the main structure is in 'Graph' and is a Javascript object of 'prefixed id' - node/way/relation mappings. Prefixed ids are n1 for nodes, w1 for ways, r1 for relations, and so on. Asked around and this approach has been taken before. Since these ids are stored as keys in an object, they're stored as strings internally anyway, so there should be no performance difference. But, Potlatch 2 and JOSM have a stronger concept of a graph - elements in iD currently have references as ids, so a way will have nodes: [n1, n2 ... nk] and these are 'resolved' by a graph.fetch method. But this probably needs to be actually represented in the code, to make things like 'finding all nodes without way parents' faster - a serious bottleneck right now. Should this be a separate 'tree' concept or should the graph be nested itself and only contain parent-free elements at its root? - Is it worthwhile to consider circular relations in an editor? For reference, implementations: * Graph: https://github.com/systemed/iD/blob/master/js/iD/graph/Graph.js * Operations: https://github.com/systemed/iD/blob/master/js/iD/actions/operations.js Thanks for the knowledge as always! -Tom On Tue, Nov 6, 2012 at 9:54 AM, Andy Allan gravityst...@gmail.com wrote: On 5 November 2012 18:11, Alex Barth a...@mapbox.com wrote: Notes here: https://github.com/systemed/iD/wiki/Check-in-Nov-05-2012 From the notes: @tmcw: I would love anyone else to look at this and try fixing / proofing some of the work (RichardF, Allan, JOSM team) Can you / Tom elaborate on this? Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSMstats lingo
Hey all, Reading this recent TPM article on OSM (in the wake of SOTMUS)[1], I noticed that it cites 550 german mappers making edits each week, and links to OSMstats. The number looks like it's just determined from the graph titled No. of daily active members (week). This title is pretty tricky - it could be (and was) read to imply that it's a weekly number, rather than a weekly range of data. Could we change this to something like Active Mappers Per Day I don't think that it's necessary to indicate in the title the range of the data - that's pretty clear from the axis. Ideally this would make the numbers clearer, since the number of mappers per week is neither the sum nor the average of mappers per day, we should make sure not to imply that this graph exposes that number. Tom [1]: http://idealab.talkingpointsmemo.com/2012/10/openstreetmap-part-2-new-cartographers.php?ref=fpb [2]: http://osmstats.altogetherlost.com/index.php?item=countriescountry=Germany ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Notes - OSM improvements BoF at SOTM PDX
The problem I see is, other than pointing to planet.openstreetmap.org I'm not sure where else we would send them? While there are lots of other places to get things like regional extracts they are unofficial third party sites so I don't think that we should be referring people to them from the main site. I think pointing people to jXAPI could work, or one thing. And, the whole 'unofficial third party sources' bit isn't that strong; planet.osm.orgpoints to third-party sources, and so does the wiki. In short, they exist and are useful, and I think it makes sense to reduce the number of logical leaps you need to take to get from A to B, because I'd assume a ton of people are getting lost along the way. On Tue, Oct 16, 2012 at 11:32 AM, Eric Marsden eric.mars...@free.fr wrote: fr == Frederik Ramm frede...@remote.org writes: fr In Wikipedia, all user-to-user messages are automatically public fr (unless both parties agree to take it to email). Maybe food for fr thought - do we need private messages at all? There seem to be fr quite a number of bullies in OSM who send self-important messages fr to lesser experienced mappers explaining their rules... that fr could be stopped if all messages were public. Are you talking about the OSMF DWG? -- Eric Marsden ___ 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] OSM Wishlist
Hey Sly, This only is my opinion, but wishlists shouldn't be reduced to those subscribed to dev@ Maybe start on dev, but I think a wiki page should better be suited for a summary of the ~3/5 tasks to focus on. Yes and no. Everything is a trade between being totally open (announce it on IRC and see what the crowd thinks!) and being totally productive (hole up and just do it until you're done and then realize it's duplicated effort). For the 'we have tasks' stage, I'd like to handle this in GitHub issues, because they are focused on doing things. There are existing wiki pages for improvements (top ten tasks, api 0.7, improving openstreetmap) which have shown at best mixed success of staying updated and being good for the 'actual doing things' collaboration phase. Tom On Mon, Oct 15, 2012 at 6:08 AM, sly (sylvain letuffe) li...@letuffe.orgwrote: On vendredi 12 octobre 2012, Tom MacWright wrote: Hey all (or, well, those subscribed to dev@ - my flamewar shields are at 50% so I'm not risking an email to talk), This only is my opinion, but wishlists shouldn't be reduced to those subscribed to dev@ Maybe start on dev, but I think a wiki page should better be suited for a summary of the ~3/5 tasks to focus on. What do you want to see happen with OSM's software this year? So many things on my side that I don't see how we can decide this on a mailing list in one thread. Better list, then short list, then vote (or kind of) and focus on few tasks. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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] OSM Wishlist
I'd love to get back to the topic of what's next. At least my at-the-moment thought for why dev@ has been more efficient than the mailing list is something pretty simple: when people post on here with some bit of knowledge - like saying that something is already implemented, or that there are potential performance problems, it's easy to know who said it, and to ask for further information. This has been vital so far, since this is a serious learning process as far as prior art. If we sign every post on the Wiki (wiki-discussion style with ~~~), that might constitute some improvement, but there's still no easy way of messaging as well as writing there. On Mon, Oct 15, 2012 at 9:37 AM, Matt Amos zerebub...@gmail.com wrote: On Mon, 2012-10-15 at 18:13 +0200, Paweł Paprota wrote: top ten tasks is These are the Top Ten Tasks that the OSM System Administrators What about the community ? This only is a todo list by the admins, for the admins coded by the admins. So far so good, but that's not a wishlist, or, at least, not a wishlist of the community. the page says: These are the Top Ten Tasks that the OSM System Administrators would really like your development help on. so i think it's unfair to say it's a list by the admins, for the admins. the important part of the sentence is ... would really like your development help on. we (EWG) formulated this list as a curated selection of tasks that we thought were generally important so that people who were looking for something to do would have some idea of what the most important[1] items were, and where their efforts would be most appreciated. Disclaimer: I have just started working on OSM a few weeks ago so I may be wrong with my impression about how things work. Generally I would say that OSM works like a typical open source project - people who do the actual programming work choose what they want to work on. That's OK since this characteristic is the main attraction to open source for programmers around the world - they can work on what they like, instead of working on what their boss or a customer order them to work on. exactly - there are no restrictions on what you should work on. the data is open, the software is open, and you can work on whatever is interesting to you. and if, surrounded by this huge number of different things to work on, you want to work on something that some people who are knowledgeable about OSM think is important enough to have short-listed; that's the Top Ten Tasks[1]. I think every open source project, including the big ones has some challenges with user voice being heard or at least that's the impression. If you propose to change it by creating a community-driven (instead of admin-driven as you put it) wishlist, by any means - do it. The operative word being do. one problem (which probably started this thread) is that a wishlist is potentially infinite. and, even treating it as an ideas-gathering forum, the value becomes diluted with the quantity of ideas presented. the hardest part of making the process useful is curating the list of wishes and doing the work of turning it into a list of achievable and practical items. and, as you rightly point out, the operative word is do. cheers, matt [1] this is not to say that other things aren't important. when the Top Ten Tasks were written, our crystal ball was out of order so we sadly couldn't predict the future. things change, and ten is much too small a number to get everything that's important onto the list, so the TTTs are a just a suggestion - they're not gospel. ___ 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] OSM Wishlist
Hey Sly, The simple answer is that MapBox (including myself) is finding ways to improve OpenStreetMap. Some of these are pretty obvious (design!), and some of them require a very high level of knowledge (API changes). By posting here, I'm trying to get a good idea of what exists, what experts think about problems and priorities, and what other issues need addressing. What this is, is neither voting on community suggestions nor is it rule from your friendly overlord. Life is full of middles. That said, let's talk less about talking and your personal suspicions and more about actual substance; aka un-derail this thread. Tom On Mon, Oct 15, 2012 at 4:03 PM, sly (sylvain letuffe) li...@letuffe.orgwrote: Le lundi 15 octobre 2012 18:13:34, Paweł Paprota a écrit : - people who do the actual programming work choose what they want to work on. I think this is a little different here (this thread) than usually is (even with what usually happen with OSM core development) Tom started this thread with : So, along with the big 'kicking off' blog post on MapBox[1] (...) What are the tasks which everyone agrees on, but nobody has had the time to tackle? [1]: http://mapbox.com/blog/kicking-off-knight-work/ By everyone I assume he meant everyone on the dev list (or everyone of the osm community) which is another way no to say What task do I want to work on And reading the linked blog about the big 'kicking off' what I understand is that he is not saying the MapBox team is going to work on what they want but Build in the open : to allow anybody in the OpenStreetMap community to engage and to facilitate a transparent process In the end, what I understand of his OSM Wishlist thread, is that he wants to start work at some intentionally broad, but it aims to: 1. Improve editing of OpenStreetMap data 2. Make the OpenStreetMap experience more social 3. Make it easier to get data out of OpenStreetMap And since this is really broad, he is willing to gather tasks, agreed by the OSM community. they can work on what they like, instead of working on what their boss or a customer order them to work on. Maybe we are in between on this thread ;-) If you propose to change it by creating a community-driven (instead of admin-driven as you put it) wishlist, by any means - do it. The operative word being do. I'll be glad to do so, and will start it. Unless the MapBox team (and tom) doesn't want to look at such a process (in the end gathering wish never read is just going to spend my time) -- sly (sylvain letuffe) ___ 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] OSM Wishlist
Okay, so visual changeset tools, better history tools, and osmbugs. OSMBugs or something like it will definitely get some love - early on we've just been battling confusion about wtf OSMBugs is, with all of the versions. That's mostly cleared up now. Anything else? On Fri, Oct 12, 2012 at 6:25 AM, Mike N nice...@att.net wrote: On 10/12/2012 3:27 AM, Stephan Knauss wrote: So I want a tool that makes it possible to do a quality control by checking diffs like it's possible in wikipedia for years. The problem is that our data is a lot harder to diff. +1 for a wishlist: visual changeset diff? __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Wishlist
@Pawel: totally, I think those are awesome. I was mostly prodding this thread since it was getting into the details of changeset/history improvements and don't want it to be laser-focused on the technical details of one thing :) On Fri, Oct 12, 2012 at 8:38 AM, Paweł Paprota ppa...@fastmail.fm wrote: Okay, so visual changeset tools, better history tools, and osmbugs. OSMBugs or something like it will definitely get some love - early on we've just been battling confusion about wtf OSMBugs is, with all of the versions. That's mostly cleared up now. Anything else? Have you read my e-mail to the list? :-) http://lists.openstreetmap.org/pipermail/dev/2012-October/025751.html I'd say these are more important than history or QA tools but that's just my opinion... Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSM API Improvements work
Hey dev, Just posted the first few issues of the work that I can deem 'stuff that we're doing as part of the Knight iniative'. They consist of API-related tasks, some of which have had prior art but haven't been tested/completed enough to ship. I'd like to get them done and shipped to make some substantive improvement in the API. The first three are: * JSON formatting for API calls and GeoJSON for some of them. Basically just making things friendly for Javascript and other JSON-era languages. * Filtering the API endpoints, so that POI editors don't have to sift through road data, and so on. * A TagInfo-like API for 'commonly used tags' ( see on https://github.com/openstreetmap/openstreetmap-website/issues?direction=descsort=createdstate=open) There are a few more tasks to come - stuff like the possibility of an Oauth 2 client flow, a complete user API for stuff like user photos stats. Some of the tasks might not be necessary, some might be in need of technical reframing (what should be done in cgimap instead?): if you've got (constructive) input, please give it! Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API Improvements work
Hey Ian, all of these things already exist as part of other tools. The story of OSM :). JXAPI is awesome. The purpose of this JSON-work would be to have a JSON API that is read/write and that is 'the API' on osm.org. If it's possible to add writing to JXAPI, that might be a better technical path to go down? TagInfo's API is certainly pretty good, and it might be good enough. Possibly this would be taginfo, or just a very small subset of what taginfo provides - my general objective is to reduce the number of apis and types of apis you need to understand count on being stable in order to write an editor. There's more than one technical way to get there. On Thu, Oct 11, 2012 at 3:31 PM, Ian Dees ian.d...@gmail.com wrote: Tom, all of these things already exist as part of other tools. JSON formatting and filtering for API endpoints exist as part of jxapi ( https://github.com/iandees/xapi-servlet). TagInfo has an API that's fairly well done. What did you have in mind to improve it? On Thu, Oct 11, 2012 at 2:26 PM, Tom MacWright t...@macwright.org wrote: Hey dev, Just posted the first few issues of the work that I can deem 'stuff that we're doing as part of the Knight iniative'. They consist of API-related tasks, some of which have had prior art but haven't been tested/completed enough to ship. I'd like to get them done and shipped to make some substantive improvement in the API. The first three are: * JSON formatting for API calls and GeoJSON for some of them. Basically just making things friendly for Javascript and other JSON-era languages. * Filtering the API endpoints, so that POI editors don't have to sift through road data, and so on. * A TagInfo-like API for 'commonly used tags' ( see on https://github.com/openstreetmap/openstreetmap-website/issues?direction=descsort=createdstate=open) There are a few more tasks to come - stuff like the possibility of an Oauth 2 client flow, a complete user API for stuff like user photos stats. Some of the tasks might not be necessary, some might be in need of technical reframing (what should be done in cgimap instead?): if you've got (constructive) input, please give it! Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSM Wishlist
Hey all (or, well, those subscribed to dev@ - my flamewar shields are at 50% so I'm not risking an email to talk), So, along with the big 'kicking off' blog post on MapBox[1], I posted three basic issues in the openstreetmap-website tracker - JSON support, filtering on the main api, and a tag api. The three of these were closed by Tom Hughes, which is fine - they might be all bad ideas, and if we're treating the issue tracker as Stuff we all agree is definitely good, then they don't belong there: they're relatively undiscussed ideas, since I had just posted them. But that's beside the point of this email: What do you want to see happen with OSM's software this year? What are the tasks which everyone agrees on, but nobody has had the time to tackle? Tom [1]: http://mapbox.com/blog/kicking-off-knight-work/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Wishlist
Hey, I haven't seen anything specifically rulling it out, but would I be right in saying that mapbox don't have plans to contribute to P2? No current plans, though that's more for lack of any experience in Flash Flex than anything set in stone or technical. Given that we currently don't plan to have some kind of P2 beater that takes its place in the edit tab, it might make a lot of sense to take a closer look at doing some targeted improvements of it. Thanks for your input! I had also totally forgotten about the deleted map item call - that should totally be on the list. Tom On Thu, Oct 11, 2012 at 8:14 PM, Andy Allan gravityst...@gmail.com wrote: On 12 October 2012 00:58, Tom MacWright t...@macwright.org wrote: Hey all (or, well, those subscribed to dev@ - my flamewar shields are at 50% so I'm not risking an email to talk), Bear in mind that technical (generally software) stuff is often better on dev@ anyway - and there's lots of developers on this list who aren't subscribed to the general flamewar^Wtalk@ list. The three of these were closed by Tom Hughes, which is fine - they might be all bad ideas, and if we're treating the issue tracker as Stuff we all agree is definitely good, then they don't belong there: they're relatively undiscussed ideas, since I had just posted them. We have rails-dev@ was the place to discuss matters relating to the api/website, and here for matters with a wider impact. Does discussing new ideas on github bring advantages over mailing lists that I'm missing? It's not something that I'm used to. What do you want to see happen with OSM's software this year? What are the tasks which everyone agrees on, but nobody has had the time to tackle? Ah, good stuff. There's a lot of stuff on Potlatch2 that I'd like to see, but that I don't have time to work on. There's a junction editor that needs writing, an in-editor tutorial framework that needs finishing off, and a lot of half-done stuff in translations, UI and unit testing. I haven't seen anything specifically rulling it out, but would I be right in saying that mapbox don't have plans to contribute to P2? Beyond that, I'd like to see the issues around the deleted-item-map-call sorted out, and OWL (or equivalent) integrated into the rails port to power the history tab. As for all-new things, I'd like to explore how to integrate all the various QA feeds into a combined overview, rather than having to hunt around different sites. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? So afaik, there is no public core site (even an old development version), and no public source for OSB (even an old branch). ^ If that's wrong, please correct with URLs and information. On Tue, Oct 9, 2012 at 4:15 PM, Tom Hughes t...@compton.nu wrote: On 09/10/12 21:01, Alex Barth wrote: I'm trying to understand the status of OpenStreetBugs and where development is happening. I think you are confusing two (or more) completely different things. I was trying to follow along at the EWG meeting yesterday. Parsing through the wiki [1] now I remain confused. Here are my questions: - Why are there two sites: osmbugs.org and http://openstreetbugs.** schokokeks.org/ http://openstreetbugs.schokokeks.org/? The Wiki says there are but not why [1]. - What is the canonical repository right now? Or is the project essentially forked? I find three repositories [2, 3, 4]. - What issue tracker should I look like? - What's the right site to link point people to? schokokes or osmbugs.org? The message on http://osmbugs.org/ is really confusing: This page is no longer a redirect; the original OpenStreetBugs web page is still available [here](http://openstreetbugs.**schokokeks.org/)http://openstreetbugs.schokokeks.org/) . All those are independent third party sites created by individuals and are not directly related to core site. I know TomH is working on updating the status on http://wiki.openstreetmap.org/**wiki/Top_Ten_Taskshttp://wiki.openstreetmap.org/wiki/Top_Ten_Tasks- apologies if I'm jumping the gun, I hope my questions are helpful to clarify the situation for anyone who wants to get involved in OSMBugs. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Some more notes on OSM vector-tiling
Hi Sandor, Is any of this work open source, or have open specifications on the web? Statements like comparisons between filesizes of raster vector data need to be cited. Tom On Fri, May 25, 2012 at 8:44 AM, Sandor Seres sandor...@gmail.com wrote: Scale/zoom levels and tiling are essential for mapping servers, especially if pretending on streaming transmission model. In case of a vector/parametric data transmission service the scale levels’ generation and the tiling of these, as a rule, is performed in quite a different way compared to the traditional raster format based service (keep in mind that a well constructed vector format may 20 – 40 TIMES be smaller than the corresponding PNG raster format for the same content). We do an OSM vector transmission based service for mobile apps (see www.fasterimaging.com). As someone properly emphasized a clipping is essential for any vector tiling. But, while clipping of line-work objects (roads, streets, borders …) is rather trivial, clipping of area objects is somewhat more complex and complicated issue. Besides the clipping, some kind of area reconstruction/restructuring has to be done (one container area may be clipped into many parts, the same with the corresponding holes, the restructuring has to decide which new holes are in which new areas, than the issue of trivial tiles or empty tiles and tiles inside areas and so on). Also, tiling inevitably results in a considerably larger data amount compared to the original dataset. So, the question is – is it possible to provide a server that combines the tiling’s efficiency and the data size at certain, close to optimal, level. Fortunately, latest research and an experimental version of such a server show that the answer is yes. The experiments are performed on OSM vector data for Europe from some weeks ago (Roughly 30 object classes/layers, 12 area classes like rivers, lakes, forests, sea …, 12 line-work classes like roads, streets, paths, water lines … and some point object classes. POIs and LBSs are overlays on such a base map). The estimates also show that such a very simple server (no DB, no caching …) is fully realistic with extraordinary performance (respond to tens of thousands requests per second) and scalability (just make a new copy as needed). A white paper, describing in more details the above subject, is available. Though in bullets format with many illustrations and with a working title – Hybrid data format, multi tiling and a new server model. Interested? Sandor ___ 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] OSMCoastline
Hey, Whoah! Nice work. All of these osmium-related projects are really exciting, can't wait to have more performant and efficient parts of the OSM stack. Plus, they're well-written and hosted on GitHub :) Tom On Wed, Mar 7, 2012 at 9:57 AM, Jochen Topf joc...@remote.org wrote: Hi! I have been working on writing a substitution for the aging coastcheck program. It is not finished yet, but maybe somebody wants to play around with it. It takes not even 20 minutes to extract all coastline data from a planet file and create polygons from it. That's at least an order of magnitude faster than coastcheck does it. More info in my blog at http://blog.jochentopf.com/2012-03-07-osm-coastlines.html Code at https://github.com/joto/osmcoastline . 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using custom renderer with mod_tile
Hi there, There's no need to swap out Mapnik - it's a general purpose renderer which can run on any kind of data. You might want to check out https://github.com/mapnik/mapnik/wiki/LearningMapnik for an intro of Mapnik it's styling language(s) Tom On Wed, Feb 29, 2012 at 2:14 PM, Skye Book skye.b...@gmail.com wrote: Hi all, We're looking to setup mod_tile to serve arbitrary tiles (i.e: not OpenStreetMap). Is there a way to change out the use of Mapnik in favor of running another application/script/whatever to render the tile to disk? Thanks, -Skye ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
