Re: [osmosis-dev] Streaming Replication
Very interesting work! How do you handle new incoming requests. They have to start from a known point so I guess you have to do an SQL query for each of them? Or do you just read the existing .osc files from disk and stream them out? This could take a long time... Jochen On Sat, Oct 13, 2012 at 03:43:32PM +1100, Brett Henderson wrote: Date: Sat, 13 Oct 2012 15:43:32 +1100 From: Brett Henderson br...@bretth.com To: osmosis-dev osmosis-dev@openstreetmap.org Subject: [osmosis-dev] Streaming Replication Hi All, For those of you who currently use the minute diffs to keep a local database up to date, you may be interested to know that a new form of replication has hit the street. The current replication system is based on a series of static replication files that are placed on a web server for clients to download as described here: http://wiki.openstreetmap.org/wiki/Planet.osm/diffs#Using_the_replication_diffs It is a very simple mechanism and works well for the existing daily, hourly and minutely replication feeds. Unfortunately it doesn't work well for sub-minute replication because it becomes far too chatty. On the server side, the current feeds are generated from cron which also works well down to one minute intervals, but the overhead of launching a new process and connecting to the database for every replication interval also becomes too inefficient for shorter intervals. To solve this, a new streaming replication mechanism has been developed. Under the covers the same database queries are utilised, but the process performing the queries runs continously and polls the database for changes at a shorter interval. It is currently set to poll every 10 seconds, but it can be reduced further if required. The network transport is also continuous and holds a single HTTP connection open for the lifetime of communication between the server and client. It is all implemented within the latest version of Osmosis 0.41. If you wish to experiment with the server-side tasks however, several bugs have been fixed in the latest development version. Internally it uses the JBoss Netty framework which means that it's all event-driven (ie. doesn't require a thread per client) and should theoretically support a large number of concurrent clients. To quickly see this in action, point your browser at this URL and you should see new replication state data become available approximately every 10 seconds. http://planet.openstreetmap.org/replication/streaming/replicationState/current/tail New Osmosis tasks have been developed to consume this data. For some basic instructions to help you get started, refer to this link: http://wiki.openstreetmap.org/wiki/Osmosis/Replication#Client-side_Streaming If you don't wish to use Osmosis, some basic documentation on the wire protocol is available here: http://wiki.openstreetmap.org/wiki/Osmosis/Replication#Streaming_Replication_Wire_Protocol This is very much experimental and bugs will undoubtedly be encountered to please be wary about trusting it to update your database if you've just spent two weeks importing a planet file. However, I'd love to see it get some usage and would welcome any feedback. This is not intended for use in updating a local planet file as the existing daily files are better suited to that. For databases that can tolerate a minute delay, the existing mechanism is very simple and has proven to be fairly reliable. But if you really need current access to data, and can cope with the additional complexity, this should be useful. The current 10 second delay is not a lower limit, but is a good starting point for now. Cheers, Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] java.lang.AbstractMethodError: org.openstreetmap.osm.data.osmbin.v1_0.OsmBinV10Writer.initialize
Hi Kim, On 13 October 2012 00:36, KHOO KIM HWA khoofu...@yahoo.com wrote: Hello, I got some errors when I try to convert .osm to osmbin file by executing: osmosis --read-xml file=idf_main_roads_new.osm --write-osmbin-0.6 dir=./osmbin-full-map-dir Thread for task 1-read-xml failed java.lang.AbstractMethodError: org.openstreetmap.osm.data.osmbin.v1_0.OsmBinV10W riter.initialize(Ljava/util/Map;)V at org.openstreetmap.osmosis.xml.v0_6.XmlReader.run(XmlReader.java:95) at java.lang.Thread.run(Unknown Source) Can someone give me some ideas to fix the problems? This error appears to be coming from an Osmosis plugin, not Osmosis itself. The plugin will need to be updated to support the latest version of Osmosis. If you can't get a newer version of the plugin you'll need to downgrade to version 0.39 of Osmosis. Recent versions of Osmosis require all tasks to support a new initialize method. Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] Streaming Replication
Hi Jochen, On 14 October 2012 06:17, Jochen Topf joc...@remote.org wrote: Very interesting work! How do you handle new incoming requests. They have to start from a known point so I guess you have to do an SQL query for each of them? Or do you just read the existing .osc files from disk and stream them out? This could take a long time... It just reads existing .osc files. The server-side is made up of two processes. The first process extracts data from the database and writes .state.txt and .osc files in a similar way to existing replication but it runs continuously using a single database connection. The second process serves the data to clients. The two processes talk via an internal HTTP-based channel so that the extracter can notify the data server when new intervals have been processed. The two processes can be run in a single Osmosis process, but I usually run them separately. It could take a long time to download a long time interval, but it is perhaps faster than you'd expect. I suspect that in most cases the bottleneck will be client side trying to consume the data. I've thought about writing the data into a database instead, but it's more effort to both develop and manage. I'm planning to wait to see if it becomes an issue. Downloading bulk data should be relatively rare because most connected clients should be up to date and just waiting for new data to arrive. One other thing to note is that it supports a tree of servers where one master server feeds data to any number of slaves which in turn feed data to end users. Example commands are here: http://wiki.openstreetmap.org/wiki/Osmosis/Replication#Streaming_Caching Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] Improved text rendering in Mapnik
Hermann Kraus-2 wrote As my Google Summer of Code project I worked on improving Mapnik's text rendering. The most important change was adding support for complex scripts, but I also implemented some other nice features. You can read more about my work here: http://mapnik.org/news/2012/10/06/gsoc2012-status9/ Build instructions are included and I would like to hear about your success stories, but bug reports are also welcome. Hi, thanks for this great bunch of features. I especially like the possibility to label boundaries correctly with the displacement parameter. Unfortunately this feature has the side effect that the displacement parameter now depends on line orientation and thus breaks my style where I use the displacement parameter to move labels that they appear above the lines. I would like to see an option like line-orientated-displacement=false or similar to get the old behaviour back if you need it. Best regards, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/Improved-text-rendering-in-Mapnik-tp5730315p5730343.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] Improved text rendering in Mapnik
On Sat, Oct 13, 2012 at 03:44:01AM +0200, Hermann Kraus wrote: As my Google Summer of Code project I worked on improving Mapnik's text rendering. The most important change was adding support for complex scripts, but I also implemented some other nice features. You can read more about my work here: http://mapnik.org/news/2012/10/06/gsoc2012-status9/ Build instructions are included and I would like to hear about your success stories, but bug reports are also welcome. Wow, thanks a lot! I was especially waiting for the upright= functionality. In an application I'm planning to use this, I would actually prefer to use an alternate text if it is turned upside down (because I'd like to print - that way or that way - depending on rotation). Something like: TextSymbolizer upright=alternate alternate_text=[name_right][name_left]/TextSymbolizer or (maybe easier): TextSymbolizer upright=only_left[name_left]/TextSymbolizer TextSymbolizer upright=only_right[name_right]/TextSymbolizer Do you think this would be possible? greetings, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Plepelits, | | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' signature.asc Description: Digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] help.osm.org - platform migration research
Hi all, During the EWG meeting last week I volunteered to research migration feasibility for the help.osm.org platform migration due to i18n problems with current software (OSQA). I have started putting together some content on the wiki (see [1]), if you want to get involved, either by suggesting new software candidates or by providing more in-depth information for a specific candidate, please do. BTW, this is only a research - migration is just one of the options to resolve this Top Ten Task - so it does not mean that help.osm.org will be moving away from OSQA. The purpose of this exercise is to provide alternatives. [1] http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks/Progress/Support_for_multiple_languages_on_help.osm.org#Update_.28October_2012.29 Paweł ___ 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] Improved text rendering in Mapnik
I am testing this and got the following error: Traceback (most recent call last): File ./generate_xml.py, line 205, in module serialize(template_xml,options) File ./generate_xml.py, line 81, in serialize mapnik.load_map(m,xml,True) RuntimeError: Unable to process some data while parsing 'osm.xml': * attribute 'unlock-text' with value 'true' at line 6 * attribute 'unlock-text' with value 'true' at line 12 * attribute 'unlock-text' with value 'true' at line 18 * attribute 'unlock-text' with value 'true' at line 57 * attribute 'unlock-text' with value 'true' at line 63 besides this, the text now really looks a lot better! cheers, Martin ___ 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] OSM Wishlist
Imagine there is list of schools in a city. This list is maintained by a school district office with updated website, phone numbers, and office opening times. They maintain this list through a simple PHP form on their website that allows them to make updates to each listing (node). If any node on their list is changed by anyone but them or the people listed as able to edit that form on their own website (with their OSM Ids) then they are notified and can correct or confirm acceptance of the change. They do not need to be the last editors of the node to know that the information contained therein is approved by them. Nobody can block somebody else from editing something. If you mean approve in this direction, it would pretty never happen. However, the school district can fork the Planet into an own database and move newer edits as act of approvement to its database. This is a typical use case of the idea of federated databases. No work has been done so far, but the point * Tools to move, merge, and diff objects between different OSM databases is surely a good point for the tools list. The federated databases will also solve most issues around imports, including patching an updated import without damaging exisiting data. The second approach is to get a concise report of all updates that happened. It is then up to the stuff of the school district to rollback or accept the edits. Concering tools to watch updates, a lot of things have happened very recently. However, none of these tools work perfectly for the school district case yet, but this will significatly improve in the next weeks. Roland ___ 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
Re: [OSM-dev] Improved text rendering in Mapnik
On Sat, 13 Oct 2012 14:11:41 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: I am testing this and got the following error: [...] * attribute 'unlock-text' with value 'true' at line 6 This is a typo in the documentation. It's unlock-image instead of unlock-text. Should be fixed in a few minutes when github updates the page. BTW: I would propose to discuss issues with no direct relation to OSM on mapnik's mailing list only. Sorry for forgetting to include this notice in the original cross-post. Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] multipolygon relation and non-closed ways
On Mon, Oct 8, 2012 at 1:10 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/10/7 Pedro Larroy pedro.larroy.li...@gmail.com: Looks like multipolygon relations can be more complex that what I was assuming. I will fix my code. Looking carefully I see that there is no contradiction. I was assuming member ways had to be closed. don't know in which language you are coding but there is the Osmium framework which does multipolygon processing out of the box: http://wiki.openstreetmap.org/wiki/Osmium cheers, Martin Thanks for the link. I have updated the wiki with requirements for valid multipolygon relations: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions Pedro. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] multipolygon relation and non-closed ways
Hi, On 13.10.2012 21:35, Pedro Larroy wrote: Thanks for the link. I have updated the wiki with requirements for valid multipolygon relations: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions I made a few changes to your list in the Wiki. (Frankly I am surprised that you thought the list was necessary, as I believed everything to be explained properly already.) First of all, the role is not actually required to determine validity, and I have removed your references of ... belonging to the same role. The algorithm laid out on the multipolygon page takes care of any valid multipolygon whatever the role; and algorithms relying on the role are broken. The use of the inner/outer roles is recommended because it adds redundancy and will often make it clearer what the mapper intended to do, but these roles are not a condition for validity. Also, the ways in a mutlipolygon relation do not have to form a closed chain (your words) but one or more closed chains. You wrote that inner polygons should not overlap with outers; I changed that to must because the polygon is invalid otherwise. Also, your rule that no more than two unclosed ways may meet in a point is not correct in the case of touching inner rings, where any even number of unclosed ways might touch in one point. 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] OSM API Improvements work
On Thu, Oct 11, 2012 at 03:39:52PM -0400, Tom MacWright wrote: 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. Taginfo has always been intended as a sort of hub to collect information on tag usage and bring it to those who need it. It has the web UI but I had always hoped people would also use the API to add this functionality to editors and the like. I encourage you to look at what the taginfo API has to offer. What is especially interesting and what you'll never get out of the OSM API is access to information like the tag descriptions from the Wiki. The taginfo API and taginfo itself has been very stable for almost a year now. I don't forsee any major changes. But if there are changes, the API contains a version number, so we can keep backwards compatibility. Note that the taginfo API was mostly written to support the Web UI, just because thats what was needed, but we could certainly add special API calls or additional parameters or so, if thats whats needed. Discussions about the details should probably happen on the taginfo-dev list. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] multipolygon relation and non-closed ways
On 10/13/2012 09:49 PM, Frederik Ramm wrote: Hi, On 13.10.2012 21:35, Pedro Larroy wrote: Thanks for the link. I have updated the wiki with requirements for valid multipolygon relations: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions I made a few changes to your list in the Wiki. And I reverted your related change to the riverbank page. It looks like you misunderstood the picture. Area 2 is modeled as a (simple) polygon, so indeed way 3 has to be closed. Area 1 is modeled as a multipolygon, so way 1 can actually consist of multiple ways. -- --- m.v.g., Cartinus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] multipolygon relation and non-closed ways
I see, thanks. On Sat, Oct 13, 2012 at 10:11 PM, Cartinus carti...@xs4all.nl wrote: On 10/13/2012 09:49 PM, Frederik Ramm wrote: Hi, On 13.10.2012 21:35, Pedro Larroy wrote: Thanks for the link. I have updated the wiki with requirements for valid multipolygon relations: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions I made a few changes to your list in the Wiki. And I reverted your related change to the riverbank page. It looks like you misunderstood the picture. Area 2 is modeled as a (simple) polygon, so indeed way 3 has to be closed. Area 1 is modeled as a multipolygon, so way 1 can actually consist of multiple ways. -- --- m.v.g., Cartinus ___ 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] multipolygon relation and non-closed ways
Hi Thanks for you edits. So for overlapping inner polygons the only way to differentiate them is by tagging as far as I can see. From the link you posted, in case#9 you need to use the role to build the polygons for example: http://postgis.refractions.net/docs/images/st_isvalid09.png Otherwise, looking at the Algorithm page that you mentioned, doesn't the step RA-4 become ambiguous? In this particular case there would be 3 ways that start at one of the nodes where the inner polygon is touching the outer thus several ring possibilities depending on which way is choosen. I was looking also at complete_ring in osmium's builder.hpp, and seems to me that it just chooses the first suitable. The algorithm that I'm using stores the endpoint on a hash to make the rings, so if there's more than two is not possible to have an clear result. Am I missing something here? Pedro. On Sat, Oct 13, 2012 at 9:49 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 13.10.2012 21:35, Pedro Larroy wrote: Thanks for the link. I have updated the wiki with requirements for valid multipolygon relations: http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions I made a few changes to your list in the Wiki. (Frankly I am surprised that you thought the list was necessary, as I believed everything to be explained properly already.) First of all, the role is not actually required to determine validity, and I have removed your references of ... belonging to the same role. The algorithm laid out on the multipolygon page takes care of any valid multipolygon whatever the role; and algorithms relying on the role are broken. The use of the inner/outer roles is recommended because it adds redundancy and will often make it clearer what the mapper intended to do, but these roles are not a condition for validity. Also, the ways in a mutlipolygon relation do not have to form a closed chain (your words) but one or more closed chains. You wrote that inner polygons should not overlap with outers; I changed that to must because the polygon is invalid otherwise. Also, your rule that no more than two unclosed ways may meet in a point is not correct in the case of touching inner rings, where any even number of unclosed ways might touch in one point. 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: Streaming Replication
Hi All, Hi Brett, To solve this, a new streaming replication mechanism has been developed. Under the covers the same database queries are utilised, but the process performing the queries runs continously and polls the database for changes at a shorter interval. Nice feature, it might not be of interest to everyone but people operating a ro mirror for editing purpose might have interest. And that's my case, so thanks for that ! However, I'd love to see it get some usage and would welcome any feedback. Here I am allready ! I've plugged that to my test server's overpass db updates and things seams to work as expected. Let's see how it performs in case of network hickups note : I have a strange issue with all objects's timestamp, they seam to be shifted by -1 hour -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API Improvements work
On Sat, Oct 13, 2012 at 4:00 PM, Jochen Topf joc...@remote.org wrote: On Thu, Oct 11, 2012 at 03:39:52PM -0400, Tom MacWright wrote: TagInfo's API is certainly pretty good, and it might be good enough. I encourage you to look at what the taginfo API has to offer. I'd love to have sensible tags suggested for me. If I add name = Walmart, an editor that suggested the most-popular value for shop=* would be really useful. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM API Improvements work
2012/10/14 Richard Weait rich...@weait.com: I'd love to have sensible tags suggested for me. If I add name = Walmart, an editor that suggested the most-popular value for shop=* would be really useful. Yes, that would be in fact a much needed feature for beginners but also for expert mappers. @Jochen: taginfo is a very valuable service which I use regularly. But it seems to me that taginfo is rather a browsing tool and has not been designed to return key-value suggestions given a single search term, right? Taginfo has strong linking capabilities but wants you rather to know the key or the value term in advance. For example: A search for castle returns castle_type (instead of historic=castle, see http://taginfo.openstreetmap.org/search?q=castle ). A search for monastery (or church) it returns the same term again (instead of place_of_worship=*). And seaching in non-english language is even worse. That's why I suggested something I called TagFinder. You can look at the showcase here http://openpoimap.ch/tagfinder/search?q=Schloss . And I'm giving a talk about how ony could add value to taginfo statistics at the OGRS conference coming soon http://www.ogrs2012.org/ . So, taginfo is rather close to that simple search with tag suggestion feature. In fact, you know that I suggested a patch for such an API - which you rejected at this time. I would still love to see taginfo enhanced with this feature (even if i would turn something like TagFinder obsolete). Yours, Stefan 2012/10/14 Richard Weait rich...@weait.com: On Sat, Oct 13, 2012 at 4:00 PM, Jochen Topf joc...@remote.org wrote: On Thu, Oct 11, 2012 at 03:39:52PM -0400, Tom MacWright wrote: TagInfo's API is certainly pretty good, and it might be good enough. I encourage you to look at what the taginfo API has to offer. I'd love to have sensible tags suggested for me. If I add name = Walmart, an editor that suggested the most-popular value for shop=* would be really useful. ___ 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] multipolygon relation and non-closed ways
Imho it's not only bad behavior to change a wiki page 19 times on the same day it's harming OSM. Having the discussion on the OSM-dev list makes this even worse. http://wiki.openstreetmap.org/w/index.php?title=Relation:multipolygonaction =history All changes except minor should be discussed on the Talk page first. Even if you are the expert and are 200% sure that what you are writing is correct it might be misleading or even not understandable to non experts. And imho that's just the case for the new additions. Asking to be involved in discussions but changing the page without discussion is topping this. http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Recent_change_ about_validity_of_a_multipolygon_relation I'm afraid more mapper will turn away from Wiki pages when they neither can follow nor understand such frequent changes. That's harming OSM. Willi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: Streaming Replication
On 14 October 2012 09:46, sly (sylvain letuffe) li...@letuffe.org wrote: Hi All, Hi Brett, To solve this, a new streaming replication mechanism has been developed. Under the covers the same database queries are utilised, but the process performing the queries runs continously and polls the database for changes at a shorter interval. Nice feature, it might not be of interest to everyone but people operating a ro mirror for editing purpose might have interest. And that's my case, so thanks for that ! However, I'd love to see it get some usage and would welcome any feedback. Here I am allready ! I've plugged that to my test server's overpass db updates and things seams to work as expected. Let's see how it performs in case of network hickups Excellent, I look forward to feedback. note : I have a strange issue with all objects's timestamp, they seam to be shifted by -1 hour Really? I might have to look into this this evening (currently 2pm Melbourne time). I previously had a few issues with timezones (BST to UTC confusion), but I thought they were limited to the information in state files, not the data itself. Brett ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Streaming Replication
One extra bit of info that might be of interest. There are a number of different URLs supported by the server. They are described here: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--send-replication-data_.28--srd.29 To summarise: - You can download just state information, or state plus data. - You can download from now, from a particular replication sequence number, or from a particular point in time (ie. timestamp). - You can download until available replication intervals are exhausted and then disconnect, or you can tail the data and be sent data immediately as it becomes available The Osmosis client-side task --receive-replication downloads state plus data, always processes from a particular sequence number, and works in tail mode. Brett ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
