Re: [OSM-talk] Slim mode in osm2pgsql and out of memory error
Stephan Knauss stephans-server.de> writes: > A while ago I did import the planet on my windows machine (i7 920, 12G). > I had used -C 3800. So you could give it a bit more ram. > I have no exact data, but I think it did run for two or three days. Thank you Stephan! We will give this a try. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik rendering labels for unrecognised tags
Anthony wrote: Sounds good. I don't think storing these in OSM, with the non-overlapping tags, is harmful. While I'd love to see them in a separate database or at least a separate layer, the fact of the matter is that separate database and/or separate layer hasn't yet really been implemented. This is the real problem! With more and more historic mapping material coming on line, and what seems like little support for the start_date/end_date tagging of physical objects that we have fairly accurate data on when they did make an appearance or when they were redeveloped, linking to other data sources where this information can be stored would at least allow it's integration? And the creation of 'temporary' layers where material is being worked on but has not yet been fully integrated would also seem to be a way forward even for general mapping? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik rendering labels for unrecognised tags
On Tue, Aug 30, 2011 at 3:36 AM, Lester Caine wrote: > Anthony wrote: >> >> Sounds good. I don't think storing these in OSM, with the >> non-overlapping tags, is harmful. While I'd love to see them in a >> separate database or at least a separate layer, the fact of the matter >> is that separate database and/or separate layer hasn't yet really been >> implemented. > > This is the real problem! > With more and more historic mapping material coming on line, and what seems > like little support for the start_date/end_date tagging of physical objects > that we have fairly accurate data on when they did make an appearance or > when they were redeveloped, linking to other data sources where this > information can be stored would at least allow it's integration? > > And the creation of 'temporary' layers where material is being worked on but > has not yet been fully integrated would also seem to be a way forward even > for general mapping? Yeah. I don't think it would be too hard to hack something up that implements the basic API (enough to run JOSM against) and uses SQLite as a backend. This would be runnable by basically anyone, and good enough for small dataset "layers" like this one. Add in the ability to export to .osm format (very simple) and you could basically run Mapnik against it with no changes, with or without first merging with other datasets and/or OSM proper. But then, while I say it "wouldn't be too hard", it would probably take a few weeks of full time coding, which unfortunately is something I don't have for something that isn't going to help me pay the bills. So as much as I hate to see these things in the main db, I'm accepting of it. Hopefully someone else will read this email, understand what I'm talking about, and love the idea, though :). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Google Summer of Code Documentation Sprint
Hi All, Some of you might remember a while back Ian Dees asked for volunteers for a GSoC Documentation Sprint. We applied to the sprint and were accepted! So myself, Ian Dees and Shaun McDonald will be going to Mountain View, California the week of October 21st to work on improving some of the OSM documentation. Below is what our proposal was: "A free map of the entire world is a compelling reason to sign-up for OpenStreetMap, but getting started with map editing can be difficult. By having a getting started guide that can easily be translated into many languages we hope to reduce the barrier to entry. Earlier efforts to make a concise, easily accessible document have grown out of date and stale, so we hope to start fresh with a document that can be easily translated, is useful both online and offline, and is easily maintained. It is important to us to end up with a document that can be printed and used in the field, since a majority of our new users contribute to the project while away from the computer. Our team hopes to create documentation that can be used immediately but also improved in the future. This requires the ability to easily get new translators up to speed and store the document in many different formats. By having this in place we can then continue to improve the getting started guide over time and be able to recruit new contributors more easily." Please note this does not mean we are starting over with documentation, though it might read that way. We are more concerned with compiling what is out there, updating it and have it set-up in a way that is easy to translate and print. Thanks! -Kate ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Overpass API: new version 0.6.93, now with meta data
Hello everybody, I proudly present the new version 0.6.93 of Overpass API. Overpass API now also provides the OSM meta data (timestamp, version, changeset id, user name, and user id). This allows to use the data directly in e.g. JOSM, including re-upload. It is the most-requested feature at the moment. Other features are a hardening of the software against file errors. The statement now allows an attribute "limit" to limit the size of the response. And a reworked planet import should now work about faster than before. Read more information on http://wiki.openstreetmap.org/wiki/Overpass_API For the next version, which should be 0.7, I'll enable bounding boxes also directly for ways and relations. Furthermore, the scripting language will get some clean-up around the query statement and a concise semantic suitable for effective GET requests. I hope, I'll complete that version in September. Some details about the meta data: As expected, this is twice as much more data (65 GB instead of 35 GB) and makes the server an order of magnitude slower. To mitigate the effects on those that don't need meta data, the feature must be explicitly requested. In OSM script, this is done via setting the respective statement to mode="meta". In the XAPI compatibility layer, add the directive [@meta]. The meta data give rise to the following special keys inside the XAPI compatibility layer: [@meta] lets the database include meta data (version, timestamp, changeset id, user name and user id). [@user=Roland Olbricht], [@uid=65282] restricts the data to data last edited by the user. He or she can be identified by name or by user id. [@newer=2011-08-01] restricts the data to only those data last edited after the given date. This is only possible in combination with another conditional. The corresponding tags in the scripting language are: instead of for the print statements that shall print meta data. , can be used as a standalone statement and as a sub-statement of a query statement. can only be used as sub-statement of a query statement. The [@changeset] special key is not realized. I want to keep up the possibility to restart at any time for a recent Planet.osm, and that Planet.osm won't contain elements that have been deleted meanwhile. Even worse, the same is true for an old version referred in the changeset if the element has been changed since then. A so much crippled response isn't useful any more. These problems do have also an impact on the user and newer queries, but I estimate them to be still useful. Cheers, Roland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] How to start to remove non-CT compliant data..
I think the strategy to remove all non-CT compliant data in one big bang is flawed. The best result for OSM is going to be obtained if the core data is nearly clean by the day of the relicencing, so that the removal of the remainder has the least possible impact. However, to accomplish that, some incremental deletions or revision hiding could help us get to that point with substantially less effort. The category I think we should address now is where the v1 is created by a person who has agreed to the CT, and subsequent revisions are by a person who has explicitly declined the CT. Specific sub-categories where an automated process could possibly remove or hide non-CT latest revisions are.. 1. Where additional nodes have been added to or removed from a way that are members of only that way and do not extend the way. 2. Where a node has been moved from its previous location by less than, say, 1m. 3. (With more complexity) Where change to a way results in no part of the way moving by more than, say, 1m, and no additional connections have been added. 4. Where tags outside a set of defined core tags have been added or removed. If we don't like the idea of this automated deletion/revision hiding, an alternative (or a complementary strategy) that would make the corresponding manual task easier would be for the API to permit hiding of the last version of a object if it is non-CT compliant. The only way that I can think of to effectively manually deal with this data now is to delete the object, load an earlier version and copy it, and re-upload to the database. The current reversion strategies all keep the non-CT data in the version chain, making it vulnerable. In doing this manual process, valuable CT-compliant history information is lost. In some areas the amount of data where there is a CT-compliant v1 but non-CT-compliant later revision can be over 50% of objects. In my limited experience examining these areas it appears that many of these changes are quite small, often small node movements, or a couple of nodes added to smooth a way, or single tags added to a large number of objects. The manual effort to ascertain what has actually changed is currently large, and risk of wasting the effort of future editors in modifying a non-CT compliant object is real. Ian.___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to start to remove non-CT compliant data..
On 31 August 2011 10:19, Ian Sergeant wrote: > > I think the strategy to remove all non-CT compliant data in one big bang is What about the people that agreed to the CTs that had data compatible with the current license, cc-by-sa ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to start to remove non-CT compliant data..
John Smith writes: > On 31 August 2011 10:19, Ian Sergeant wrote: > > > > I think the strategy to remove all non-CT compliant data in one big bang is > > What about the people that agreed to the CTs that had data compatible > with the current license, cc-by-sa ? What about the people who didn't agree to the CT, but whose data is in the public domain? -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to start to remove non-CT compliant data..
On 31 August 2011 15:43, Russ Nelson wrote: > John Smith writes: > > On 31 August 2011 10:19, Ian Sergeant wrote: > > > > > > I think the strategy to remove all non-CT compliant data in one big bang > is > > > > What about the people that agreed to the CTs that had data compatible > > with the current license, cc-by-sa ? > > What about the people who didn't agree to the CT, but whose data is in > the public domain? Exactly, accepting or not accepting the CT might be a suitable indicator for the majority of mappers, but it won't tell you if the data is suitable for relicensing, lots of people have been told they can accept the CTs because they allow for accepting the current license. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to start to remove non-CT compliant data..
Russ Nelson wrote on 31/08/2011 03:43:28 PM: > What about the people who didn't agree to the CT, but whose data is in > the public domain? Hi Russ, The suggestion here is to streamline a process, more than determine policy.. That is to.. 1. Automatically hide trivial changes to objects originally created by those who have agreed to the CT by people who have specifically declined them. And/Or 2. When edits made by those who have specifically declined the CT are manually reverted, allow them to be hidden from the history of the object, so the object can then be determined to be fully CT-compliant throughout its history. If our objective is a CT-compliant data-set, I see both of these things as advancing us towards that objective, doing little or no damage, saving us considerable manual effort in some areas, and saving the history of objects where we can. It also may avoid unnecessarily large data removal at a later stage. To address your question specifically, what happens to data placed in the public domain by the author on the wiki, who then specifically declines the CT? Well in the first case, if the edits are just a trivial modification to a fully CT-compliant version - I'd say just hide them. In the second case, where a CT-compliant editor has decided to revert the edits made by one of our ambivalent PD editors, they are being reverted anyway, so the only concern is the state of the history of the object and not the state of the object itself. The editor when choosing whether to revert currently could just as well decide to copy and upload to avoid the possibility of contamination, with the effect of losing all the history connection to the object. Which is preferable? I'd say hiding the history of the edit by ambivalent PD contributor is preferable to losing all connection, so I'd recommend that. Ian.___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
