Re: [OSM-dev] Hello World
Le jeudi 18 octobre 2012 22:41:26, Alex Barth a écrit : On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.orgMapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I wonder how good the current Mapnik style is for editors. By mapnik I asume you are refering to the standard map at osm.org IMHO : it is not good enough for editing purpose. see http://wiki.openstreetmap.org/wiki/Contributors_functionalities_wishlist#Backgound_map_with_the_most_possible_objects the problem is that the Mapnik style completely ignores `surface=unpaved` making a significant dirt road really not look how it should on the map. Arguably, the standard map might or might not show that information if we see it as a general purpose map. But as an editing purpose map like, it would be a great addition. But several other features also would : place=isolated_dwelling sac_scale=* or trail_visibility=* comes to by mind, but it could be extended to any approved feature in the wiki or at least any approved with a certain threshold of uses. -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Hi, I'd be very happy to have a new map style free (or almost free) of POIs, in order to leave the selection of categories to the user. It is currently done by 3Liz company, thanks to their LizPoi demo http://lizpoi.3liz.com/demo/index.php/lizpoi/map/?tree_id=1 (by the way, POIs are clickable) This is one of my favorite way to show how rich and diversified the database information can be Works best so far with Mapquest tiles as background 2012/10/12 Michal Migurski m...@teczno.com Hi everyone, My wishlist: * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Just sifting through the thread again … I like this idea for connecting people as they're editing… I guess it's worthwhile pointing out that when we wrote into the Knight proposal 'better social tools' we were thinking less 'post my latest change to twitter' - extreme example, noone suggested we would - but more like 'how can we connect mappers better?'. For instance: I'd like to know better who's mapping in any areas I have mapped. In Portland someone had the idea of notifying me if someone modified data in an area I've just recently worked on. For instance: currently we're showing mappers' home locations on our user profiles - I don't find that as useful as showing mappers who've recently mapped in an area I'm interested in - doesn't need to be my home town. On Oct 12, 2012, at 5:28 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 12.10.2012 23:13, Paweł Paprota wrote: * Social OSM: feh, don't care. I accept that there are different views on that topic. Ultimately I think the project can greatly benefit from having more mappers (through better osm.org usability and social-ability). My take on social OSM is a combination of these views - feh because I myself am really not interested in your friend Peter mapped a post box yesterday!; but I can see that there *are* people who would like that kind of thing and if we can offer it to them - all the better. There are also a number of interesting things that I would perhaps not use, but like to toy with as a coder - for example I've long been thinking, wouldn't it be cool if an editor were showing a little chat box to the side where you would be connected live to the people editing in the same city right now? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.orgMapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I wonder how good the current Mapnik style is for editors. Mapping in Latin America I'm for instance noticing more and more how people tag major connecting roads `highway=track` because they're unpaved instead of using an appropriate tag such as `highway=tertiary` and specifying `surface=unpaved`. Tagging for the renderer of course: the problem is that the Mapnik style completely ignores `surface=unpaved` making a significant dirt road really not look how it should on the map. I guess it's clear that there's an issue w/ the style not being maintained right now and it's unclear how to contribute to it, but based on stuff like the unpaved road example I'm starting to think that the Mapnik style does not only need a refresh esthetics wise but it being unmaintained complicates good mapping. Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Thu, Oct 18, 2012 at 4:41 PM, Alex Barth a...@mapbox.com wrote: On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.orgMapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I wonder how good the current Mapnik style is for editors. Mapping in Latin America I'm for instance noticing more and more how people tag major connecting roads `highway=track` because they're unpaved instead of using an appropriate tag such as `highway=tertiary` and specifying `surface=unpaved`. Tagging for the renderer of course: the problem is that the Mapnik style completely ignores `surface=unpaved` making a significant dirt road really not look how it should on the map. I guess it's clear that there's an issue w/ the style not being maintained right now and it's unclear how to contribute to it, but based on stuff like the unpaved road example I'm starting to think that the Mapnik style does not only need a refresh esthetics wise but it being unmaintained complicates good mapping. I think the current Mapnik style should eventually be replaced by a CartoCSS style (hosted on GitHub) that is accessible to more editors/cartographers (think TileMill). It should maintain the focus of showing everything under the sun, even if it is a bit cluttered. There's lots of great general purpose styles (MapBox Streets, Open MapQuest) and more focused ones out there, the main OSM.org style should be a showcase of the underlying data. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Oct 18, 2012, at 1:41 PM, Alex Barth wrote: On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.orgMapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I wonder how good the current Mapnik style is for editors. Mapping in Latin America I'm for instance noticing more and more how people tag major connecting roads `highway=track` because they're unpaved instead of using an appropriate tag such as `highway=tertiary` and specifying `surface=unpaved`. Tagging for the renderer of course: the problem is that the Mapnik style completely ignores `surface=unpaved` making a significant dirt road really not look how it should on the map. I guess it's clear that there's an issue w/ the style not being maintained right now and it's unclear how to contribute to it, but based on stuff like the unpaved road example I'm starting to think that the Mapnik style does not only need a refresh esthetics wise but it being unmaintained complicates good mapping. The unpaved thing feels like something that would be added to the current style, rather than an excuse to tear it down and start fresh. I'm not a big believer that moving to Github and CartoCSS *alone* (just to cite two ideas from this thread) will be sufficient to make the Mapnik style easier for people to approach. That's probably an easy strawman to knock over. =) My feeling is that setting up a different style, built from the ground-up to be a better presentation of OSM to the general public rather than mappers gets us closer to the goal more easily, and does so without hitting the whole replace the map style issue too hard. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Am 13.10.2012 00:40, schrieb Michal Migurski: How does a new map style typically graduate to use on OSM.org as an option? See http://wiki.openstreetmap.org/wiki/Tile_Layer_Guidelines My personal view on this is that anybody expecting that simply replacing the current default displayed style with a different one will change anything is kidding himself in a big way. The pressure to include everything and the kitchen sink will not go away and instead just refocus. It might be good idea to change the misleading labelling of the default style to make it clear that we don't think the standard for an OSM data derived map should be totally overloaded, but again that is just me. Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
2012/10/13 Simon Poole si...@poole.ch: My personal view on this is that anybody expecting that simply replacing the current default displayed style with a different one will change anything is kidding himself in a big way. The pressure to include everything and the kitchen sink will not go away and instead just refocus. It might be good idea to change the misleading labelling of the default style to make it clear that we don't think the standard for an OSM data derived map should be totally overloaded, but again that is just me. While the inclusion of some stuff (or the integration in lower zoom levels, e.g. leisure=* on nodes in Z15, pubs in Z16) provokes in some areas the feeling that the map is overloaded, there are still missing some traditionally important features (e.g. city gates (or their names) are usually still a main reference in older cities). What would be really nice is a zoom level dependent display based on the density. In a rural area the one church/pub/hotel/camping... might merit to be displayed also on zoom 14 or 15, while in a dense urban area it shouldn't show up before z17/18 for example. The same is also valid for roads to a certain degree (if there aren't any motorways in a country you would want to see the primaries earlier, e.g. in a desert region with sparse population). I know this kind of stuff is quite complicated to do, at least in real time it might be (almost) impossible. But given the amount of brilliant people contributing to OSM, maybe there is a way? cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
It is not necessarily about changing WHAT is displayed but changing HOW it is displayed. Current style is simply not up to the standard in terms of esthetics for a project that aspires to be more than a database. Pawel Simon Poole si...@poole.ch wrote: Am 13.10.2012 00:40, schrieb Michal Migurski: How does a new map style typically graduate to use on OSM.org as an option? See http://wiki.openstreetmap.org/wiki/Tile_Layer_Guidelines My personal view on this is that anybody expecting that simply replacing the current default displayed style with a different one will change anything is kidding himself in a big way. The pressure to include everything and the kitchen sink will not go away and instead just refocus. It might be good idea to change the misleading labelling of the default style to make it clear that we don't think the standard for an OSM data derived map should be totally overloaded, but again that is just me. Simon ___ 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] Hello World
Am 13.10.2012 13:55, schrieb Pawel Paprota: It is not necessarily about changing WHAT is displayed but changing HOW it is displayed. Current style is simply not up to the standard in terms of esthetics for a project that aspires to be more than a database. I suspect (well actually I know) that you will find a very wide range of opinions on your later statement, from supporting having no public map at all (just a database) to the full blown google look-a-like. That specific discussion is however very off topic for the dev list. Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
I am aware of and accept different point of views about the project. I am only speaking my own opinion and also I don't agree that it is not a discussion for dev list. Right now there is a unique chance to get restyling a shot because Mapbox is involved and obviously they have the expertise to do it or at least initiate and maybe lead the effort. I do agree that wishful thinking threads do not belong on dev mailing list but I would say that right now a discussion like this should happen here, again because of Mapbox folks looking for areas to be improved. I would love to hear from them on this topic, preferably with all the gory technical details (mapnik 0.x vs 2 etc). Pawel Pawel Simon Poole si...@poole.ch wrote: Am 13.10.2012 13:55, schrieb Pawel Paprota: It is not necessarily about changing WHAT is displayed but changing HOW it is displayed. Current style is simply not up to the standard in terms of esthetics for a project that aspires to be more than a database. I suspect (well actually I know) that you will find a very wide range of opinions on your later statement, from supporting having no public map at all (just a database) to the full blown google look-a-like. That specific discussion is however very off topic for the dev list. Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Hi, On 13.10.2012 00:25, Mikel Maron wrote: I'll add here, internationalization of tiles would be a key development. Especially with some of the recent edit wars Korea/Japan/China over island names and possession. Jochen is doing some work on that for the Wikimedia Foundation at the moment, basically using Matt's open-sourced MapQuest rednering stack as the backend for multilingual bitmap tiles. I expect that if we are interested we could use his results. He occasionally reports on his progress on blog.jochentopf.com. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Mike, On 13.10.2012 00:40, Michal Migurski wrote: * Generalized and merged dual carriageways for mid-zoom labels, * City label placements for low-to-mid zooms generated with simulated annealing, * Route shields based on route relations, * Merged transit points. There's often a tradeoff between making a beautiful map and making a current map. I have a feeling that some of the things you mention might actually incur quite a lot of processing time. On OSM we're used to have current maps. Our default mapnik map updates just minutes after you have made a change. The tile layer guidelines for our front page say Services maintaining minutely updates preferred, but periods up to two weeks may be acceptable depending on the content of the map.; help.openstreetmap.org is full of I've made a change why doesn't it show questions. Most of the current techniques for doing stuff like generalization are based on a give me the full planet file and I'll render it approach and are unsuitable for incremental updates; i.e. you would have to have a fat machine that generalizes the planet once every night or something. It is a very interesting technological challenge to make such algorithms capable of handlings diffs - for each derived, generalized object you'd have to store a pointer to the source objects, and invalidate the generalized object when a change occurs in one of the constituent objects. That would then pave the way to have current *and* beautiful maps. I haven't managed to solve that yet and it would be great if somebody did, but I fear it is not something that can be done quickly. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Oct 13, 2012, at 5:41 AM, Frederik Ramm wrote: Mike, On 13.10.2012 00:40, Michal Migurski wrote: * Generalized and merged dual carriageways for mid-zoom labels, * City label placements for low-to-mid zooms generated with simulated annealing, * Route shields based on route relations, * Merged transit points. There's often a tradeoff between making a beautiful map and making a current map. I have a feeling that some of the things you mention might actually incur quite a lot of processing time. That is definitely the tradeoff I have in mind, yes. On OSM we're used to have current maps. Our default mapnik map updates just minutes after you have made a change. The tile layer guidelines for our front page say Services maintaining minutely updates preferred, but periods up to two weeks may be acceptable depending on the content of the map.; help.openstreetmap.org is full of I've made a change why doesn't it show questions. Most of the current techniques for doing stuff like generalization are based on a give me the full planet file and I'll render it approach and are unsuitable for incremental updates; i.e. you would have to have a fat machine that generalizes the planet once every night or something. I was thinking once per week or so, but yeah: the generalized parts would have to be done on an offline basis periodically. It would take longer for changes to migrate to this layer. It fills a need for better-looking, easier to use cartography that isn't just a simple rasterization of the vectors in the database, digitized as they are at a particular scale. It also keeps the present Mapnik layer available for mappers, with its up-to-date content derived from a live change stream. Up-to-the-week is still quite current for most people's needs, and distinct from the up-to-the-minute needs of mappers. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Hello World
Hi everyone, I've been following the OSM Wishlist thread via the list archives on the web and thought I'd pop in to join the discussion. I feel of two minds about the suggestion: on the one hand, I'm thrilled to see energy from Tom, Alex and the Mapbox team. On the other, I feel like the OSM community is about to experience a full-court press and needs to build up some structure to match. I'm excited to see what Mapbox comes up with hear, but I think it would be a misuse of the Knight grant to develop a bucket of tools without the admin time to support their long-term use. My wishlist: * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. * Improved relation + data model support in a editors, either a new one or a retrofit onto Potlatch. Things like route relations or addressing schemas are important, for example, and should see the same kind of first-class support in an editor that the primary/secondary/etc. road schema does. It's time for these higher-order features to come out of the lab. * Better time-awareness in planet dumps. I want to see a days since last edit or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source. * Social OSM: feh, don't care. Stepping back, the story of OSM *is* that things happen in other tools, so I'm in agreement with Paweł Paprota that Mapbox should build something that needs JSON support, filtering and tag API before those features get fed into the core infrastructure. The minute diffs support the ability to develop real, working systems in an offboard manner, and I think we should take advantage of that. I'm also in agreement with Tom Hughes on the issue of bug trackers: issue trackers that are acquiring things at a faster rate than things are being closed have an unfortunate effect, sapping energy through administrative overhead. I use Trac and Github for issue tracking on sparingly, when issues have a clear boundary and release target. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Fri, Oct 12, 2012 at 6:14 PM, Michal Migurski m...@teczno.com wrote: * Improved relation + data model support in a editors, either a new one or a retrofit onto Potlatch. Things like route relations or addressing schemas are important, for example, and should see the same kind of first-class support in an editor that the primary/secondary/etc. road schema does. It's time for these higher-order features to come out of the lab. another item, if i may add to your wishlist, is turn restrictions; there's already some special-purpose support for this in JOSM and Potlatch 2, and i think it's something where a little more work could really help reduce the complexity of adding and maintaining these features. they tend to be found around complex junctions and there have been many ideas in the past for what a UI specifically for junction editing might look like (for example [1]). * Better time-awareness in planet dumps. I want to see a days since last edit or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source. please could you explain a little more? i think perhaps i've misunderstood what you're asking for. all nodes, ways and relations in the planet file have a timestamp, and the planet has a date header that would allow the calculation of days since last edited. would you like this information on the sub-elements (tags, nds, members) as well? Stepping back, the story of OSM *is* that things happen in other tools, so I'm in agreement with Paweł Paprota that Mapbox should build something that needs JSON support, filtering and tag API before those features get fed into the core infrastructure. The minute diffs support the ability to develop real, working systems in an offboard manner, and I think we should take advantage of that. and systems developed in this way are loosely coupled to the rails code and main database, making it easier to admin and scale these services later without adding complexity to the rails code. in my opinion, it's a huge advantage. cheers, matt [1] http://www.slideshare.net/yutik/mapzen-junction-editor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Hi Michał, * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. That's an interesting idea... the question is about infrastructure - whether it would withstand having to render two styles... (unless Mapnik style is offloaded somewhere). * Better time-awareness in planet dumps. I want to see a days since last edit or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source. Here I fully agree with what Matt said about having a network of distributed and decoupled services. Sometimes there is trouble with integrating all of this stuff (see the current QA platform discussion) but at the end of the day one of the greatest advantages of OSM is that I can download the data, heck, even the planet dump if I want, and put it on my laptop, develop some software against it and share it with the world, keep it up to date with replication. This is a great way to build a dev community. On the other hand I did stumble upon some minor inconveniences with replication - like lack of changeset metadata which is only available through the API call but there are no show stoppers that I can see. But still, lots of room to improve. * Social OSM: feh, don't care. I accept that there are different views on that topic. Ultimately I think the project can greatly benefit from having more mappers (through better osm.org usability and social-ability). And also it's great that there are people who care about data, routing, search and all the different stuff that makes this project whole. Stepping back, the story of OSM *is* that things happen in other tools, so I'm in agreement with Paweł Paprota that Mapbox should build something that needs JSON support, filtering and tag API before those features get fed into the core infrastructure. The minute diffs support the ability to develop real, working systems in an offboard manner, and I think we should take advantage of that. As mentioned above, I agree with the notion of replication-powered services. However, in this particular example, part of proposed changes in the API is supposed to make writing editors easier. I support such use case and my remark build something that needs new API's first, then think about extending API's was more about Mapbox's approach to the subject, not about my opposition to extending the API. I mean, perhaps it would be good to show concrete examples of some editor functionality that needs new filtering and tag API. I think that it could go a long way in supporting such changes, at least I always prefer to see things in proper context. I'm also in agreement with Tom Hughes on the issue of bug trackers: issue trackers that are acquiring things at a faster rate than things are being closed have an unfortunate effect, sapping energy through administrative overhead. I use Trac and Github for issue tracking on sparingly, when issues have a clear boundary and release target. +1 to that. Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Hi, On 12.10.2012 23:13, Paweł Paprota wrote: * Social OSM: feh, don't care. I accept that there are different views on that topic. Ultimately I think the project can greatly benefit from having more mappers (through better osm.org usability and social-ability). My take on social OSM is a combination of these views - feh because I myself am really not interested in your friend Peter mapped a post box yesterday!; but I can see that there *are* people who would like that kind of thing and if we can offer it to them - all the better. There are also a number of interesting things that I would perhaps not use, but like to toy with as a coder - for example I've long been thinking, wouldn't it be cool if an editor were showing a little chat box to the side where you would be connected live to the people editing in the same city right now? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Fri, Oct 12, 2012, at 23:28, Frederik Ramm wrote: Hi, On 12.10.2012 23:13, Paweł Paprota wrote: * Social OSM: feh, don't care. My take on social OSM is a combination of these views - feh because I myself am really not interested in your friend Peter mapped a post box yesterday!; but I can see that there *are* people who would like that kind of thing and if we can offer it to them - all the better. I'm not a very social person myself but when I started thinking about social in the context of OSM it hit me that it's a great fit. The thing is that on Facebook vast majority of updates that come in does not interest me at all, hence I use Facebook maybe once a week to check updates on some book authors I like or hang glider manufacturer discussion group or whatever. Now, in OSM that is completely different (for me) - I would really like to see what's going on in my area, what are people working on. I would like to be able to quickly send a broadcast and say let's go and map X and Y. So I think social OSM maybe is not the best name for this because it reminds people of Facebook's garbage I just ate a sandwich status updates. In any case, we will see how it works out, for sure I think it's worth a try. There are also a number of interesting things that I would perhaps not use, but like to toy with as a coder - for example I've long been thinking, wouldn't it be cool if an editor were showing a little chat box to the side where you would be connected live to the people editing in the same city right now? Very cool idea, not sure how many people would use it (hard to predict such things) but it aligns nicely with the idea of making communication between mappers easier. Paweł ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Oct 12, 2012, at 1:50 PM, Matt Amos wrote: On Fri, Oct 12, 2012 at 6:14 PM, Michal Migurski m...@teczno.com wrote: * Better time-awareness in planet dumps. I want to see a days since last edit or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source. please could you explain a little more? i think perhaps i've misunderstood what you're asking for. all nodes, ways and relations in the planet file have a timestamp, and the planet has a date header that would allow the calculation of days since last edited. would you like this information on the sub-elements (tags, nds, members) as well? In the case of downstream renderers and other services, it would be incredibly useful to have a planet with a known degree of volatility. If vandalism or an edit war affects the stability of an area, I would be interested in seeing what the last-known-stable versions of those entities look like and rendering from there. The street I live on has been untouched since 2010, but if someone came along and edited it I might want that reflected in a render only after the change been allowed to stand unchallenged for some period of time (a week?). The addition to the planet could just be an additional timestamp that represented the last-changed date of all constituent ways or nodes for any relation or way. It might also be an addition to the changeset and not the planet dump. A rollup, basically, that addresses a need for a stable dump. This is something that's relatively to generate in a secondary application, but I could see it being useful for the core planet as well. -mike. michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
* Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I'll add here, internationalization of tiles would be a key development. Especially with some of the recent edit wars Korea/Japan/China over island names and possession. * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Michal Migurski m...@teczno.com To: dev@openstreetmap.org Sent: Friday, October 12, 2012 10:14 AM Subject: [OSM-dev] Hello World Hi everyone, I've been following the OSM Wishlist thread via the list archives on the web and thought I'd pop in to join the discussion. I feel of two minds about the suggestion: on the one hand, I'm thrilled to see energy from Tom, Alex and the Mapbox team. On the other, I feel like the OSM community is about to experience a full-court press and needs to build up some structure to match. I'm excited to see what Mapbox comes up with hear, but I think it would be a misuse of the Knight grant to develop a bucket of tools without the admin time to support their long-term use. My wishlist: * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. * Improved relation + data model support in a editors, either a new one or a retrofit onto Potlatch. Things like route relations or addressing schemas are important, for example, and should see the same kind of first-class support in an editor that the primary/secondary/etc. road schema does. It's time for these higher-order features to come out of the lab. * Better time-awareness in planet dumps. I want to see a days since last edit or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source. * Social OSM: feh, don't care. Stepping back, the story of OSM *is* that things happen in other tools, so I'm in agreement with Paweł Paprota that Mapbox should build something that needs JSON support, filtering and tag API before those features get fed into the core infrastructure. The minute diffs support the ability to develop real, working systems in an offboard manner, and I think we should take advantage of that. I'm also in agreement with Tom Hughes on the issue of bug trackers: issue trackers that are acquiring things at a faster rate than things are being closed have an unfortunate effect, sapping energy through administrative overhead. I use Trac and Github for issue tracking on sparingly, when issues have a clear boundary and release target. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ 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] Hello World
On Oct 12, 2012, at 2:13 PM, Paweł Paprota wrote: * Social OSM: feh, don't care. I accept that there are different views on that topic. Ultimately I think the project can greatly benefit from having more mappers (through better osm.org usability and social-ability). And also it's great that there are people who care about data, routing, search and all the different stuff that makes this project whole. I should maybe have phrased this better. Social stuff is not on my wishlist but I can see that it would be valuable to someone. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Oct 12, 2012, at 3:25 PM, Mikel Maron wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I'll add here, internationalization of tiles would be a key development. Especially with some of the recent edit wars Korea/Japan/China over island names and possession. Agreed. How does a new map style typically graduate to use on OSM.org as an option? I am interested in collaborating on this with someone. A potential issue is that I think this needs to be a high-quality style with some data-processing features that would introduce a rendering delay: * Generalized and merged dual carriageways for mid-zoom labels, * City label placements for low-to-mid zooms generated with simulated annealing, * Route shields based on route relations, * Merged transit points. The colors should keep the current blue/green/red/orange/yellow OSM rainbow scheme because it's an important visual indicator, but with sharply reduced saturations so the map has adequate pure-luminance contrast. Fonts should be bigger and easier to read across the board. Abbreviations should be used when available and generated when not. We're doing some work at Stamen to take our Terrain map worldwide, and we'll be using and documenting a number of these techniques. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
Mikel Maron wrote * Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. My suggestion would be for osmf to provide two main styles. An improved version of the current style for mappers and a vector tile layer for use with client side rendering like e.g. KothicJS. These two styles would be different enough to imho warrant the extra infrastructure needed, while still fitting the description of osmf's main objective. For the client side rendering one can then offer as many different styles as one likes. For non-editor style bitmap maps I think it is probably for now better to rely on third party renders in order to not stretch the infrastructure too thinly. For inclusion of third party styles on osm.org the procedures are listed under http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines Mikel Maron wrote I'll add here, internationalization of tiles would be a key development. Especially with some of the recent edit wars Korea/Japan/China over island names and possession. Wikimedia Germany is currently funding a project to develop improved internationalized maps in all of the 200+ languages of Wikipedia. So hopefully we will see some progress on this in not too long a future. There is also already the current batch of internationalised maps ( http://toolserver.org/~osm/locale/ ), although the current version scales poorly and so its performance is somewhat problematic. Kai -- View this message in context: http://gis.19327.n5.nabble.com/Hello-World-tp5730232p5730304.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Fri, Oct 12, 2012 at 6:40 PM, Michal Migurski m...@teczno.com wrote: A potential issue is that I think this needs to be a high-quality style with some data-processing features that would introduce a rendering delay: * Generalized and merged dual carriageways for mid-zoom labels, * City label placements for low-to-mid zooms generated with simulated annealing, * Route shields based on route relations, * Merged transit points. I agree that the default OSM.org tiles should be separate from a more mapper/debug-focused design (as I would say the current Standard style is) and also agree that in order to do this the data needs to be tweaked more than is likely possible in 'real-time'. I would love to join an effort to make this a reality. We're doing similar/related data pre-processing at MapBox which I'll be detailing in my SOTM-US talk on Sunday. Currently we do this as a one-off pre-render step (since we generate our rendering databases with Imposm), but I would love to discuss ideas about integrating such render-focused optimizations into a minutely-Mapnik system with anyone who's interested, either in Portland or online. -- AJ Ashton ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
