Re: [OSM-talk] [OSM-dev] NOTICE: Upcoming Maintenance / Downtime
On Mon, Nov 25, 2013 at 6:34 AM, Grant Slater openstreet...@firefishy.com wrote: On Wednesday 27th of November 2013 between 17:30 and 22:00 (GMT / UTC) the primary database server will be unavailable due to maintenance. I apologise for the short notice. Grant, thanks always to you and to the full admin team, for making OpenStreetMap work and work well. I appreciate your constant attention to the nitty bits and the gritty bits of OpenStreetMap infrastructure, keeping everything up and running. The way that you make frequent improvements and additions to OpenStreetMap Foundation services is wonderful. Your immediate attention and rapid response to unscheduled events is exemplary. Thanks so much. You admins should be paid in more than just thanks. Not just for your continued expertise, but for the ten years of commitment so far. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] NOTICE: Upcoming Maintenance / Downtime
Hi, On Mon, Nov 25, 2013 at 10:23:43AM -0500, Richard Weait wrote: Grant, thanks always to you and to the full admin team, for making OpenStreetMap work and work well. I appreciate your constant attention to the nitty bits and the gritty bits of OpenStreetMap infrastructure, keeping everything up and running. The way that you make frequent improvements and additions to OpenStreetMap Foundation services is wonderful. Your immediate attention and rapid response to unscheduled events is exemplary. Thanks so much. You admins should be paid in more than just thanks. Not just for your continued expertise, but for the ten years of commitment so far. Sysadmin appriciantion day is on 28th of July :) SCNR Flo PS: http://de.wikipedia.org/wiki/System_Administrator_Appreciation_Day -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Tilesets on DVD/CDROM?
On Tue, Oct 22, 2013 at 12:36 PM, Arnie Shore asho...@verizon.net wrote: All, I've googled unsuccessfully; Can someone point me to any source/vendor of subject tile sets, by say, USA county or state. I think geofabrik does provide this kind of service. http://www.geofabrik.de/maps/tiles.html -- -S ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM homepage redesign
Hi all, I note that there hasn't been a recent what developments are currently happening type email, so I'll step in with this one. At SOTM 2013 John Firebaugh (mapbox) presented an update to the SOTM US talk that explored a new vision for the openatreetmap.org website. The talk was well received and it was obvious that a lot of thought had been put in to the design to reflect feedback from the initial plans. There is now a To Do list for implementing this. I encourage you to check out the link below, watch the video, read the slides and view the mockups. If you have constructive feedback, feel free to post comments (ideally on the github page most associated to the part of the design you are commenting on). Please remember that we are all volunteering time/energy to OSM so try to keep comments constructive and avoid jumping to conclusions if something isn't quite clear. Regards, Rob https://github.com/openstreetmap/openstreetmap-website/pull/498 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM in the energy sector
To the OSM community, Last year in July, the energy sector GIS working group organised a workshop where we gave a presentation about mapping day Uganda and OSM. http://mappingday.com/content/mapping-and-gis-energy-sector-workshop 3 months later (October), the Energy Sector GIS Working Group got an award for the best Map at a GIS conference in Naivasha, Kenya. http://www.energyprogramme.or.ug/giz-uganda-gets-award-for-best-gis-map/ The guess is right :) for the winning map, it has/used OSM as a base-map!! as a result from the workshop and the presentation we gave. http://www.gis-uganda.de/Energy-GIS/ In Uganda, this week (23rd-27th September), has some activities to mark the energy week, and we shall meet once again this year with the Energy sector GIS Working group in the coming days. If there are some other related examples of how osm can be and has been used in the energy sector, besides ITO http://www.itoworld.com/map/group/16 Please share some more links, on or offlist. Thanks. Yours Truly Douglas Ssebaggala Musaazi Mobile: +256-772-422524 http://www.mappingday.com/ http://www.twitter.com/mapuganda http://www.mountbatten.net/ https://lists.openstreetmap.org/listinfo/talk-ug Keep In Touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Workshop held at Wikimania
Hi all, just to say that at Wikimania there has been a OSM Workshop[0] held by user aude (AKA Aude)[1]. We also add a very little and quick mapping party afterwards (which, personal note, was the very first mapping party I ever attended :) ). There has also been other occasion during this Wikimania to talk about Wikipedia, OSM and maps on wiki*. Cristian [0] http://wikimania2013.wikimedia.org/wiki/Submissions/OpenStreetMap_workshop [1] http://www.openstreetmap.org/user/Aude, http://www.openstreetmap.org/user/aude and http://en.wikipedia.org/wiki/User:Aude ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM server problems?
I'm getting a lot of internal server errors reported by JOSM when I download (small) areas from the server. Is there a problem with the server? Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] New tile rendering (Live Worldwide)
This is amazing. Fantastic work! On Mon, Aug 5, 2013 at 9:41 AM, Grant Slater openstreet...@firefishy.comwrote: Hi OpenStreetMappers, The default OpenStreetMap.org standard map was switched across to a new rendering server setup over the last weekend. In addition to new hardware, the rendering server also uses the new “openstreetmap-carto” stylesheet. This is a complete re-write of the old XML stylesheet to use CartoCSS, making it easier for our cartographers to work with. The style is designed to look as similar as possible to the old XML stylesheet. Andy Allan presented a great talk at State of the Map US conference describing the reasons for re-writing the stylesheet: http://stateofthemap.us/saturday.html#schedule/saturday/putting-the-carto-into-openstreetmap-cartography Andy will present a follow-up at State of the Map next month. http://2013.stateofthemap.org/ The openstreetmap-carto stylesheet is maintained here: https://github.com/gravitystorm/openstreetmap-carto The openstreetmap-carto is a good base for creating custom styles, and should be much easier to work with. If you want to help improve the style, or add new features, please fork it and contribute pull requests! Please support OSM’s server hardware fundraising drive: http://donate.openstreetmap.org/server2013/ Kind regards Grant Slater Part of the OSM Sysadmin Team ___ dev mailing list d...@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM History Viewer
Hello, Does anyone know when the OSM History Viewer (http://osmhv.openstreetmap.de) might be back up? I have been receiving the following message for the last couple of hours: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. -- Apache/2.2.16 (Debian) Server at osmhv.openstreetmap.de Port 80 Thanks, Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM History Viewer
OSM History Viewer has been like that for almost 2 weeks now. This has been reported on the service's official (?) bug reporting system by somebody 10 days ago but there has been no response: https://bugs.cdauth.eu/index.php?do=detailstask_id=80project=2 On Tue, Jul 16, 2013 at 7:28 AM, Mike Thompson miketh...@gmail.com wrote: Hello, Does anyone know when the OSM History Viewer ( http://osmhv.openstreetmap.de) might be back up? I have been receiving the following message for the last couple of hours: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. -- Apache/2.2.16 (Debian) Server at osmhv.openstreetmap.de Port 80 Thanks, Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM History Viewer
Eugene, Thanks! Hopefully it will be up soon. Mike On Mon, Jul 15, 2013 at 5:34 PM, Eugene Alvin Villar sea...@gmail.comwrote: OSM History Viewer has been like that for almost 2 weeks now. This has been reported on the service's official (?) bug reporting system by somebody 10 days ago but there has been no response: https://bugs.cdauth.eu/index.php?do=detailstask_id=80project=2 On Tue, Jul 16, 2013 at 7:28 AM, Mike Thompson miketh...@gmail.comwrote: Hello, Does anyone know when the OSM History Viewer ( http://osmhv.openstreetmap.de) might be back up? I have been receiving the following message for the last couple of hours: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. -- Apache/2.2.16 (Debian) Server at osmhv.openstreetmap.de Port 80 Thanks, Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM attributed by Korean firm Naver.
Hello everyone, I noticed recently that an OSM attribution has appeared at the bottom right on Korea's Naver mapping service. Naver is a Korean internet portal which is very popular here (er, in Korea). I don't know exactly what Naver is using OSM for, since I always assumed they acquired and maintained their own data (including their own streetview images). See the attribution for yourselves at: http://map.naver.com/ I don't know what you'll see, as Naver uses IP geolocation to estimate your starting position. Maybe outside Korea you'll be presented with Seoul. Another popular web portal is Daum. They have a map service (including streetview) but they don't acknowledge OSM, so they probably aren't using it: http://map.daum.net/?t__nil_bestservice=map Interesting? Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM on France24 international news TV channel
http://www.france24.com/fr/20130622-internet-cartographie-collaborative There may be a english version somewhere... but not sure. I'm lucky the journalist kept the best part of my way too long explanations ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Notes feature
Am 01.06.2013 01:38, schrieb Paul Johnson: Curious when the JOSM OpenStreetBugs feature will be updated to handle the new Notes system, does anyone know? See https://josm.openstreetmap.de/ticket/8193 It does not have to be either or but both will probably be supported for a while. fly signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Notes feature
Am 01.06.2013 01:38, schrieb Paul Johnson: Curious when the JOSM OpenStreetBugs feature will be updated to handle the new Notes system, does anyone know? See https://josm.openstreetmap.de/ticket/8193 It does not have to be either or but both will probably be supported for a while. fly signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Notes feature
Curious when the JOSM OpenStreetBugs feature will be updated to handle the new Notes system, does anyone know? Also curious if the Skobbler folks follow the list, and what the thoughts are of either incorporating their Mapdust category features (I find them handy) into Notes, and/or possibly merging Mapdust into Notes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Authentication Proxy
Hi! When Frederik asked about using OAuth for the GeoChat plugin, I remembered the same problem I had with the imagery offset database. And since I was in a programming mode, this lead to an idea on how to skip OAuth for client applications, while reliably identifying users. So the whole Sunday I was coding, and now I am proud to present the OpenStreetMap Authentication Proxy: http://auth.osmz.ru/ https://github.com/Zverik/osm-auth-proxy The idea is that the service, to which you log in via OAuth, generates tokens, which it can then remember and exchange for some related user info. Some tokens are permament, some work only once, so even if someone manages to steal one, it would only work until the first logout. Actually, do visit the page: most of it is filled with description text. I will probably use this service for identifying users in GeoChat and other services, and will be happy to see it being used by others. IZ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 11.05.2013 04:19, malenki wrote: colliar wrote: Am 05.05.2013 05:26, schrieb malenki: The tool replace geometry exists - at least for JOSM. It even works on replacing an old (existing) Node for a new way. Yes it is a nice tool but it only does include the node in the new way. E.g. you still have a new object representing the real world object. Cannot confirm. Right now tested on this way - the old id still is used: http://www.openstreetmap.org/browse/way/28820333 You did replace a way with a way but not a node with a way ! colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
colliar wrote: You did replace a way with a way but not a node with a way ! Of course. It should be obvious that the ID of a node cannot be transformed into the ID of a way. Using replace geometry on a existing node and a new way is the easiest way to make the existing node part of the new way (thus keeping the history of the node) and moving the tags from the node to the way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
colliar wrote: Am 05.05.2013 05:26, schrieb malenki: The tool replace geometry exists - at least for JOSM. It even works on replacing an old (existing) Node for a new way. Yes it is a nice tool but it only does include the node in the new way. E.g. you still have a new object representing the real world object. Cannot confirm. Right now tested on this way - the old id still is used: http://www.openstreetmap.org/browse/way/28820333 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi. Do you have any idea how this permanent ID could look like? You dislike the overpass-approach (and yes, it's far from perfect). What is your idea how a stable permanent ID to an object may be achieved? Let's use a shop as an example (and wikidata as the foreign database as an example, too). 1st stage: it's not mapped at all - okay, nothing to link to. 2nd stage: someone maps a shop - and only that shop, without name or anything like that. Wikidata could of course link to the osm id, even if it only contains a coordinate and shop=supermarket, but if they want to do that, they have more information they could add to osm easily, like name and usually at least parts of the address. 3rd stage: someone (e.g. the wikidata people) adds these details - the overpass-api get's slightly more stable (I know, not completely stable of course). 4th stage: someone replaces the node by a polygon mapping the supermarkets building as a whole. Now the osm id has changed, so your approach to use that as a link key fails here. 5th stage: someone refines that polygon to include the hole in the middle, so it get's a multipolygon relation. again the internal osm id changes, the overpass-api (when designed usefully) is kept. 6th stage: the name of the shop changes (small change due to corporates decision, nothing really useful): The osm id is stable here, overpass is likely to fail now (but knows about this failure as it's possible to acknowledge the dead link). 7th stage: the shop moves to another address, therefore the tags are moved to another building, let's say, 3 streets away. The OSM id looks like it's still stable, but links to the wrong object. The overpass-id is either still valid or is automatically known to be a dead link. I agree, that the overpass-api isn't perfect and it's still possible to produce links that are either (or may get) ambiguous or that may break due to any edit in future. But the internal OSM ID has even more drawbacks: while the overpass-permanent-id includes semantics for the link, the osm id is a pure technical link. I'm keen to get a better idea how that could be achieved, or why you really think that the osm id is really better than overpass with respect to stability and maintainability. regards Peter Am 07.05.2013 00:31, schrieb Stefan Keller: Hi, I also think that linking from an OSM object to a growing no. of external databases (incl. Wikipedia/Wikidata) is not a good idea. And I respect the wish of the OSM maintainers to change the OSM id in the future. But the overpass-permanent-osm-id is no solution neither, primo because a set of key-values is a clumsy id, and secondo because there exist many OSM objects which have no identifying tags (or none at all). As this issue pops up from in increasingly frequent intervals I think it's time to think about a good mid term solution (short term is sticking to the OSM id). I'm proposing a solution alongside one of the following two directions: * either to implement a Linked Data API/service which maps from permanent ids to OSM objects (and which is what I like about overpass - being a service) - * or to add a permanent id as an additional XML tag to every OSM object! And if somebody thinks that's a waste of space we can easily drop the XML tag user which is completely redundant to uid (which in turn needs another simple API to find out the current users display name). Yours, Stefan 2013/5/6 Peter Wendorff wendo...@uni-paderborn.de: Am 06.05.2013 23:07, schrieb andrzej zaborowski: Hi, On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: No, it's not. I did not speak about mapping the hospital and the merchants kontor, but about wikidata entries ahout the hospital and the merchants kontor - and wikidata in fact includes historical entities like that, too. If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. Why not? The building is the same, and it's not of interest, that the tag amenity=museum is not (any more) existent in osm. If that's an argument any wikidata entity that's not tagged as complete as the wikidata entity itself would be nothing to be linked. Your cross-reference (only add a reference osm pointing to wikidata to the building, but link all other entities of wikidata to the building) argument may be valid, but it's complex (that's my question below); but especially historical
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 07.05.2013 00:47, schrieb Tobias Knerr: Am 06.05.2013 23:55, schrieb Peter Wendorff: Am 06.05.2013 23:07, schrieb andrzej zaborowski: If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. Why not? It wouldn't add any information. The hospital should be linked to the building _within_ Wikidata anyway because there are more properties that can be attached to a building than just a OSM building outline. So if we connect the OSM building and the Wikidata building, then the hospital is already (though Wikidata) linked to the OSM building, too. If it doesn't occupy the entire building then you can probably add the museum tag on the building geometry but later once you want to add a wikidata tag you'd probably split it out like you'd split a street object when you want to add an attribute that applies to a part of the attribute. If you're into indoor mapping then you'd draw the museum outline separately anyway. so you propose to split it up because of an external ID you propose to add... While I in general agree that objects of osm are split when they get mapped in more detail (like in this example), I'm not happy to do that for the reason to enable matching to external references. Using the same OSM element for two distinct features actually contradicts a strict one feature, one OSM element principle. We do it anyway because it's convenient, but as soon as you want to add the same tag - whether it's name, opening_hours, or wikidata - to both features, you create two separate elements. That's not a special treatment of external IDs, but consistent with other tags, and using two separate elements is semantically better anyway. I agree from a theoretical point of view. But your failing assumption here is, that wikidata only would link to perfectly fine mapped stuff. If you would add that link to wikidata, you probably would divide it to several osm objects before. But is that realistic to assume, that the wikidata folks will do that, too? This would require wikidata people to entirely know the osm model, how to edit and what might be the drawback of combining features in one object. And keep in mind it's not clear in every case what to separate and what not. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, All use cases you describe are valid. It's up to the users of OSM permanent id to keep track of changing OSM ids - it's an offer of OSM. The only constraint I would propose is to avoid to delete and recreate a new id only because of a tool (like an editor) likes to do it like this. The concept of permanent, unique and never-reused object ids is a well-known property in the Object-Oriented and Linked Data technology. As I said: The killer criteria not to use overpass-approach is that there exist many OSM objects which have too few or no tags at all. And using coordinates as identifiers is no solution neither because it's a float number with different precision and implementation dependent. OO overcame exactly this restriction of the relational paradigm (which identified a tupel by the set of it's values). Responsible for the unique generation of a permanent id is finally the OSM server instance(s). In case the OSM servers are distributed a distributed id scheme is applied as in NoSQL databases and here [1]. Yours, Stefan [1] http://www.interlis.ch/oid/oid_e.php 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Hi. Do you have any idea how this permanent ID could look like? You dislike the overpass-approach (and yes, it's far from perfect). What is your idea how a stable permanent ID to an object may be achieved? Let's use a shop as an example (and wikidata as the foreign database as an example, too). 1st stage: it's not mapped at all - okay, nothing to link to. 2nd stage: someone maps a shop - and only that shop, without name or anything like that. Wikidata could of course link to the osm id, even if it only contains a coordinate and shop=supermarket, but if they want to do that, they have more information they could add to osm easily, like name and usually at least parts of the address. 3rd stage: someone (e.g. the wikidata people) adds these details - the overpass-api get's slightly more stable (I know, not completely stable of course). 4th stage: someone replaces the node by a polygon mapping the supermarkets building as a whole. Now the osm id has changed, so your approach to use that as a link key fails here. 5th stage: someone refines that polygon to include the hole in the middle, so it get's a multipolygon relation. again the internal osm id changes, the overpass-api (when designed usefully) is kept. 6th stage: the name of the shop changes (small change due to corporates decision, nothing really useful): The osm id is stable here, overpass is likely to fail now (but knows about this failure as it's possible to acknowledge the dead link). 7th stage: the shop moves to another address, therefore the tags are moved to another building, let's say, 3 streets away. The OSM id looks like it's still stable, but links to the wrong object. The overpass-id is either still valid or is automatically known to be a dead link. I agree, that the overpass-api isn't perfect and it's still possible to produce links that are either (or may get) ambiguous or that may break due to any edit in future. But the internal OSM ID has even more drawbacks: while the overpass-permanent-id includes semantics for the link, the osm id is a pure technical link. I'm keen to get a better idea how that could be achieved, or why you really think that the osm id is really better than overpass with respect to stability and maintainability. regards Peter Am 07.05.2013 00:31, schrieb Stefan Keller: Hi, I also think that linking from an OSM object to a growing no. of external databases (incl. Wikipedia/Wikidata) is not a good idea. And I respect the wish of the OSM maintainers to change the OSM id in the future. But the overpass-permanent-osm-id is no solution neither, primo because a set of key-values is a clumsy id, and secondo because there exist many OSM objects which have no identifying tags (or none at all). As this issue pops up from in increasingly frequent intervals I think it's time to think about a good mid term solution (short term is sticking to the OSM id). I'm proposing a solution alongside one of the following two directions: * either to implement a Linked Data API/service which maps from permanent ids to OSM objects (and which is what I like about overpass - being a service) - * or to add a permanent id as an additional XML tag to every OSM object! And if somebody thinks that's a waste of space we can easily drop the XML tag user which is completely redundant to uid (which in turn needs another simple API to find out the current users display name). Yours, Stefan 2013/5/6 Peter Wendorff wendo...@uni-paderborn.de: Am 06.05.2013 23:07, schrieb andrzej zaborowski: Hi, On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 07.05.2013 09:43, schrieb Stefan Keller: Hi, All use cases you describe are valid. It's up to the users of OSM permanent id to keep track of changing OSM ids - it's an offer of OSM. The only constraint I would propose is to avoid to delete and recreate a new id only because of a tool (like an editor) likes to do it like this. The concept of permanent, unique and never-reused object ids is a well-known property in the Object-Oriented and Linked Data technology. As I said: The killer criteria not to use overpass-approach is that there exist many OSM objects which have too few or no tags at all. And using coordinates as identifiers is no solution neither because it's a float number with different precision and implementation dependent. OO overcame exactly this restriction of the relational paradigm (which identified a tupel by the set of it's values). But even then overpass is slightly better: Let's say I only know I want to link a given supermarket. Let's say that supermarket is not tagged in more detail then shop=supermarket. Linking to node 123 would break soon when that get's a polygon (not to mention mappers who don't know or care about theory of data management and reuse that node directly to map a waste_basket instead of creating a new object). Best case here would be a mapper that includes that node as one of the nodes building the polygon - but who knows? Overpass in contrast could add information about: - we want to link a supermarket - it's roughly in that bounding box (e.g. the city or a given part of the city) Of course this can break, too - but it's more stable than the ID alone, even without any tag at all. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Linking to OSM objet ID looks like a bad idea because they are not stable. We had a recent long talk on talk-fr@ about permanent IDs that could help linking external data to OSM, instead of multiplying ref:xxx in OSM to link to external data. I've proposed something that can be summarized like some generic geoURL that could be used to describe something/somewhere in the form something@somewhere 'something' could use some hierarchical semantic description, and 'somewhere' could use for example geohash. Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc These geoURL can be compared with some level of fuzzyness on something and/or somewhere by reducing the level of details if necessary (exemple: shop@u09v8s9fd5 has less details and can be matched with a simple contain text search). They can be translated into whatever query like an overpass-api query to actually resolve to the current matching objets in OSM or somewhere else as the geoURL are not OSM based in any way. This mechanism works pretty well for node/polygon based POI, but needs to be extended for more linear features (like a street), maybe using more than one geohash (one at both ends ?). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, You wrote: - it's roughly in that bounding box (e.g. the city or a given part of A soon as you use the word roughly - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Yours, Stefan 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Am 07.05.2013 09:43, schrieb Stefan Keller: Hi, All use cases you describe are valid. It's up to the users of OSM permanent id to keep track of changing OSM ids - it's an offer of OSM. The only constraint I would propose is to avoid to delete and recreate a new id only because of a tool (like an editor) likes to do it like this. The concept of permanent, unique and never-reused object ids is a well-known property in the Object-Oriented and Linked Data technology. As I said: The killer criteria not to use overpass-approach is that there exist many OSM objects which have too few or no tags at all. And using coordinates as identifiers is no solution neither because it's a float number with different precision and implementation dependent. OO overcame exactly this restriction of the relational paradigm (which identified a tupel by the set of it's values). But even then overpass is slightly better: Let's say I only know I want to link a given supermarket. Let's say that supermarket is not tagged in more detail then shop=supermarket. Linking to node 123 would break soon when that get's a polygon (not to mention mappers who don't know or care about theory of data management and reuse that node directly to map a waste_basket instead of creating a new object). Best case here would be a mapper that includes that node as one of the nodes building the polygon - but who knows? Overpass in contrast could add information about: - we want to link a supermarket - it's roughly in that bounding box (e.g. the city or a given part of the city) Of course this can break, too - but it's more stable than the ID alone, even without any tag at all. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 07.05.2013 09:58, schrieb Stefan Keller: Hi, You wrote: - it's roughly in that bounding box (e.g. the city or a given part of A soon as you use the word roughly - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Then it's not the same permanent we talk about. Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now - but that's not what people usually want if they request for a permanent ID, similar to changes from node to polygon to multipolyogn etc. It's in that bounding box nevertheless would have been the better wording, (equalling is roughly at that position, so if you want to use roughly/estimation, it's possible even then). regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
2013/5/7 Christian Quest cqu...@openstreetmap.fr: Linking to OSM objet ID looks like a bad idea because they are not stable. Agreed. I've proposed something that can be summarized like some generic geoURL that could be used to describe something/somewhere in the form something@somewhere Am I understanding you correctly: You propose a kind of geoURL - like linked data [1] - which is a tag attached to OSM nodes? That would fulfill most of my criterias except that it does not indicate that it's a system property GeoHashes have a nice property of being completely independent of a centralized (or partially centralized) id generator. But they are not suited to identify object which are overlaying each other. Yours, Stefan [1] http://semanticweb.org/wiki/GeoURL 2013/5/7 Christian Quest cqu...@openstreetmap.fr: Linking to OSM objet ID looks like a bad idea because they are not stable. We had a recent long talk on talk-fr@ about permanent IDs that could help linking external data to OSM, instead of multiplying ref:xxx in OSM to link to external data. I've proposed something that can be summarized like some generic geoURL that could be used to describe something/somewhere in the form something@somewhere 'something' could use some hierarchical semantic description, and 'somewhere' could use for example geohash. Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc These geoURL can be compared with some level of fuzzyness on something and/or somewhere by reducing the level of details if necessary (exemple: shop@u09v8s9fd5 has less details and can be matched with a simple contain text search). They can be translated into whatever query like an overpass-api query to actually resolve to the current matching objets in OSM or somewhere else as the geoURL are not OSM based in any way. This mechanism works pretty well for node/polygon based POI, but needs to be extended for more linear features (like a street), maybe using more than one geohash (one at both ends ?). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now No, That's one of the nice properties of ids without coordinates! To me it would remain the same - except when a tool or the user is fooling the concept. At least the tools you can debug. Yours, Stefan 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Am 07.05.2013 09:58, schrieb Stefan Keller: Hi, You wrote: - it's roughly in that bounding box (e.g. the city or a given part of A soon as you use the word roughly - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Then it's not the same permanent we talk about. Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now - but that's not what people usually want if they request for a permanent ID, similar to changes from node to polygon to multipolyogn etc. It's in that bounding box nevertheless would have been the better wording, (equalling is roughly at that position, so if you want to use roughly/estimation, it's possible even then). regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
I'm not proposing to add this as a new tag to OSM objects, but to use these geoURL in external datasets instead of OSM IDs. It is a way to keep a (fuzzy) link between datasets. Fuzzyness seems mandatory at some level as I doubt it is possible to have an exact match between data models that are completely different. With higher and higher level of details in OSM data, it becomes more and more difficult to describe more global things. The node POI becomes a polygon POI, then maybe a multipolygon... the single way street is later divided in several ways to describe each part in details (pavement, oneway, light, trees, etc). These geoURL could be generated from lat/lon + semantic infos about an object, then resolved back to actual objects in whatever dataset (including OSM but not only). overpass/XAPI could resolve these geoURL by converting for example shop@u09v8s9fd5 into [shop=*][bbox=] as geohash are in fact bboxes. Think of it like the internet DNS system... hostname can be resolved to IP addresses and the reverse. You don't have to resolve hostname to know you're talking of the same thing but you have to in order to access it. 2013/5/7 Stefan Keller sfkel...@gmail.com: 2013/5/7 Christian Quest cqu...@openstreetmap.fr: Linking to OSM objet ID looks like a bad idea because they are not stable. Agreed. I've proposed something that can be summarized like some generic geoURL that could be used to describe something/somewhere in the form something@somewhere Am I understanding you correctly: You propose a kind of geoURL - like linked data [1] - which is a tag attached to OSM nodes? That would fulfill most of my criterias except that it does not indicate that it's a system property GeoHashes have a nice property of being completely independent of a centralized (or partially centralized) id generator. But they are not suited to identify object which are overlaying each other. Yours, Stefan [1] http://semanticweb.org/wiki/GeoURL 2013/5/7 Christian Quest cqu...@openstreetmap.fr: Linking to OSM objet ID looks like a bad idea because they are not stable. We had a recent long talk on talk-fr@ about permanent IDs that could help linking external data to OSM, instead of multiplying ref:xxx in OSM to link to external data. I've proposed something that can be summarized like some generic geoURL that could be used to describe something/somewhere in the form something@somewhere 'something' could use some hierarchical semantic description, and 'somewhere' could use for example geohash. Example for a bakery nearby my place: saines_saveurs.bakery.shop@u09v8s9fd5mc These geoURL can be compared with some level of fuzzyness on something and/or somewhere by reducing the level of details if necessary (exemple: shop@u09v8s9fd5 has less details and can be matched with a simple contain text search). They can be translated into whatever query like an overpass-api query to actually resolve to the current matching objets in OSM or somewhere else as the geoURL are not OSM based in any way. This mechanism works pretty well for node/polygon based POI, but needs to be extended for more linear features (like a street), maybe using more than one geohash (one at both ends ?). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Unfortunately I'm too busy to investigate how much elements in OSM change their meaning instead of deleting the old and creating the new object. In addition your fooling the concept is not correct. If a supermarket is abandoned, and was tagged as a building + name + shop=supermarket, you would not delete the whole object and add a new object with the building tag alone, right? regards Peter Am 07.05.2013 10:25, schrieb Stefan Keller: 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now No, That's one of the nice properties of ids without coordinates! To me it would remain the same - except when a tool or the user is fooling the concept. At least the tools you can debug. Yours, Stefan 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Am 07.05.2013 09:58, schrieb Stefan Keller: Hi, You wrote: - it's roughly in that bounding box (e.g. the city or a given part of A soon as you use the word roughly - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Then it's not the same permanent we talk about. Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now - but that's not what people usually want if they request for a permanent ID, similar to changes from node to polygon to multipolyogn etc. It's in that bounding box nevertheless would have been the better wording, (equalling is roughly at that position, so if you want to use roughly/estimation, it's possible even then). regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Say the supermarket downsizes and the other half of the building becomes used by another company. We split the building, creating 1 new building, glued to the original building. Now there is a 50% chance the existing building outline continues as the supermarket and 50% it's the new company continuing life in OSM with that way id. I'm working on our local bus stops a lot and they all have a ref displayed on them, which is very convenient to refer back to them. In the other side of the country and in Brussels, we have to make do with the name. If we ever get access to the underlying DB, we might be able to add the internal refs, which to me is still the most convenient way to identify specific bus stops. Right now there are usually at least 2 bus stops with the same name on both sides of the road. relation membership could make them unique, once route relations are added, but it complicates matters quite a bit to have to identify them that way. (I'm not talking about linking bus stops to Wikidata/Wikipedia). I need to link back to them to compare with the data coming from upstream. Or to assist in creating/verifying route relations. All that to say that, to me, ref tags on our objects seem like the most stable and practical way to identify them. Polyglot 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de Unfortunately I'm too busy to investigate how much elements in OSM change their meaning instead of deleting the old and creating the new object. In addition your fooling the concept is not correct. If a supermarket is abandoned, and was tagged as a building + name + shop=supermarket, you would not delete the whole object and add a new object with the building tag alone, right? regards Peter Am 07.05.2013 10:25, schrieb Stefan Keller: 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now No, That's one of the nice properties of ids without coordinates! To me it would remain the same - except when a tool or the user is fooling the concept. At least the tools you can debug. Yours, Stefan 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: Am 07.05.2013 09:58, schrieb Stefan Keller: Hi, You wrote: - it's roughly in that bounding box (e.g. the city or a given part of A soon as you use the word roughly - the id approach is doomed to fail. According to OO and database technology an id is a well-defined surrogate with a well-defined data type. Then it's not the same permanent we talk about. Look what happens in OSM all the time: POIs are moved slightly to match aerial images - following your definition that should be another ID now - but that's not what people usually want if they request for a permanent ID, similar to changes from node to polygon to multipolyogn etc. It's in that bounding box nevertheless would have been the better wording, (equalling is roughly at that position, so if you want to use roughly/estimation, it's possible even then). regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 07.05.2013 12:56, schrieb Stefan Keller: 2013/5/7 Peter Wendorff wendo...@uni-paderborn.de: you would not delete the whole object and add a new object with the building tag alone, right? I said that it's up to the mapper to decide - as its common in OSM. External services which link to this object through the permanent id have to cope with this. have to cope with this - but you didn't mention that when proposing to use the OSM id (alone) as a reference... regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
I guess you are all both right and wrong on this matter and thus because you are loking from single angle only. I recognize several different needs: External link to coordinates This is simply link to specific geographic coordinates. As it is not necessarily that there is an object on this coordinates that means there is no sense for such links to exist at all. External link to location Lets define location as specific place on map where object is located. It may not necessarily fixed to specific coordinates for the sole reason that coordinates may be changed for reasons like better measurements or fixed error or something like this. But, this is still just an location which may be linked externally regardless what type of object is located there. External link to an property Property is object on map that is fixed (if we disregard possibility that it may be destroyed or relocated in very exceptional conditions). Any kind of building is fine example. In some manner we may look at property and location as the same but with significant difference: location is related to geographic location and has eternal existence, and property is related on real object which is logically placed on a location but may be destroyed or (exceptionally) moved. Back to the point, external link to an object is meant to target specific object that is not moveable. External link to an property purpose Property purpose is function object has. If we see building as an property, shop located in that building would be object purpose. Object purpose is not constant. It may change. Building may have number of purposes in time, or several purposes at the same time. But if some external database contains data about number of shops it needs to link to OSM data which related for specific shop. If shop moves few blocks away, external link should still point to that very shop. So, to have database support all this needs it should have separate entities as location, property and property purpose in manner that one first defines location (with it's own ID), then defines property (with it's own ID) at that location and then attaches property purpose(s) (with their own ID(s)) for that object. Whole discussion is caused because OSM database does not support this kind of objects. It is so loosely defined that object may serve all three roles from case to case and may even change role in time. What could be solution? First, let simplify things by merging role of location and role of property as they are very similar. When new object is created in OSM database it should get it's unique ID. That ID stays unchanged until object is deleted. This is actually how thing are already done, and it will do the job for external linking to location or property. But it does not help when property purposes are needed. So, OSM database may be expanded for another ID which is created when purpose is assigned to object and if purpose of the object is changed. It also should stay unique. This other property would allow linking to property purpose. If property purpose is deleted, it's ID is also deleted, but if purpose is moved to other object (on another location) then it's ID is moved to and unchanged, so external links will still be valid. What happens when object is changed from point to multipoint or area or split? It should done in such manner that object ID is preserved, or, in case new object is created instead of an old one, some kind of relation should be established so if database is queried for old object ID it would return info about new object with new ID which is replacement. If object is split, one part preserves existing ID and other parts are considered as new objects with new ID's assigned. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
De : Mike mike.cuttl...@gmail.com I guess you are all both right and wrong on this matter and thus because you are loking from single angle only. [...] If object is split, one part preserves existing ID and other parts are considered as new objects with new ID's assigned. Hi I quite agree with Mike. Properties should have a stable ID and geometrical objects ( way,node,relations) should refer to this ID to be qualified and on the other way it should be possible to find these objects from the ID. By this way it would be easy to refer to a complex object like a motorway or country boundary even if it is made of a lot of subobjects. It would also solve the issue repeating a lot of tags on a lot of objects just because there is one change on part of the way It would be a kind of everything is a relation but I'm afraid it could mean a change in OSM API my 2 cents Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 05.05.13 14:55, Kolossos wrote: I don't like to support different reference systems in WIWOSM. I see the point. But WIWOSM seems not to work with anchor-links: Neither http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020 http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020 nor http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026 http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026 (don't know how you want spaces encoded) does find the object in OSM. And I'm not talking of a different reference system in WIWOSM. Wikipedia/Wikidata should uniquely name those objects that only exist in Wikipedia lists. We (OSM as well as WIWOSM) should only use those names. /al ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
I made a wikidata tag proposal: http://wiki.openstreetmap.org/wiki/Wikidata I think osm -- wikidata is much better than wikidata -- osm. At least while we don't have a solution for persistent ID's. Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 05.05.2013 05:26, schrieb malenki: On 04.05.2013 15:24, Paul Norman wrote: When I get new imagery for the area and re-trace the building depending on what is easiest I may end up creating a new way. The tool replace geometry exists - at least for JOSM. It even works on replacing an old (existing) Node for a new way. Yes it is a nice tool but it only does include the node in the new way. E.g. you still have a new object representing the real world object. Cheers signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hello Andreas, It seems in principle possible to support anchor-links but it was not in our focus, because our frontend had only one map per article. (You can believe me the sytem was complex enough ;-)). I will talk about this topic with my co-creator and the developer of WikiMiniAtlas. It will also have some problems with articles in different languages connected by Interwikilinks because the anchors could be different, so I would like to support it later with Wikidata part 3 (lists). Greetings Tim Am 06.05.2013 11:03, schrieb Andreas Labres: On 05.05.13 14:55, Kolossos wrote: I don't like to support different reference systems in WIWOSM. I see the point. But WIWOSM seems not to work with anchor-links: Neither http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020 http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzing%23objektid-25020 nor http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026 http://toolserver.org/%7Ekolossos/openlayers/kml-on-ol-json3.php?lang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien%2FPenzing%23objektid-25026 (don't know how you want spaces encoded) does find the object in OSM. And I'm not talking of a different reference system in WIWOSM. Wikipedia/Wikidata should uniquely name those objects that only exist in Wikipedia lists. We (OSM as well as WIWOSM) should only use those names. /al ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Do they have something like a persistent ID in wikidata, yet? Do you want to add dozens of wikidata-tags (or a comma separated value or something like that), if more than one wikidata-element matches the osm element. Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). The architect was a famous person, too, and it's named by a third person. So that osm element (building building would be referenced out of wikidata from: - the merchant's person page (his office) - the museum's page - the restaurant's page - the hospital's page - the architect's page - the page of the person where the name of the building comes from Which ID should be added to OSM here? Is that really useful? Wikidata seems to collect a lot of these links, including wiki-pages (even in different languages) and so on, so wikidata in fact is built around maintaining foreign references (at least it looks like that), while OSM is definitively not (yet). Perhaps look into the overpass-permanent-ID solution for that. regards Peter Am 06.05.2013 16:14, schrieb Janko Mihelić: I made a wikidata tag proposal: http://wiki.openstreetmap.org/wiki/Wikidata I think osm -- wikidata is much better than wikidata -- osm. At least while we don't have a solution for persistent ID's. Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 06.05.2013 18:54, Peter Wendorff wrote: Do they have something like a persistent ID in wikidata, yet? I think the Wikidata page title - something like Q35525 - is intended to be rather stable. Of course there are sometimes problems, such as duplicates or interwiki conflicts, that make it necessary to change items. But unlike unlike OSM, Wikidata actually cares about providing an ID for a distinct semantic entity. In my opinion, this is a major reason to link to Wikidata using OSM tags, and not the other way round. (Improving our data model in that regard doesn't seem realistic in the short term.) Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: - the merchant's person page (his office) Wikidata would link to their internal building item instead. Not our job imo. - the museum's page Can be linked using the wikidata key at the museum POI. - the restaurant's page Can be linked using the wikidata key at the restaurant POI. - the architect's page Can be linked using the architect:wikidata key at the building. It could be argued that we should leave that to Wikidata, though - they have an architect property for buildings themselves. - the page of the person where the name of the building comes from Can be linked using the name:etymology:wikidata key at the building. Again, we theoretically could omit this and instead rely on Wikidata's named after property. Perhaps look into the overpass-permanent-ID solution for that. In my opinion that's not really a good solution here. Manually creating Overpass API queries is too hard. Tobias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On Tue, May 7, 2013 at 2:26 AM, Tobias Knerr o...@tobias-knerr.de wrote: On 06.05.2013 18:54, Peter Wendorff wrote: Do they have something like a persistent ID in wikidata, yet? I think the Wikidata page title - something like Q35525 - is intended to be rather stable. Of course there are sometimes problems, such as duplicates or interwiki conflicts, that make it necessary to change items. But unlike unlike OSM, Wikidata actually cares about providing an ID for a distinct semantic entity. In my opinion, this is a major reason to link to Wikidata using OSM tags, and not the other way round. (Improving our data model in that regard doesn't seem realistic in the short term.) For those who are not on the tagging mailing list, the wikidata=* tag has been proposed[1], and discussed on the tagging mailing list starting late February 2013[2]. Based on my assessment of the discussion, there doesn't seem to be a clamor to add the wikidata=* tag to replace or even as an additional tag to the wikipedia=* tag. The concern is that wikipedia=* is much more easier for the average mapper to grasp than the wikidata=* tag. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata [2] http://lists.openstreetmap.org/pipermail/tagging/2013-February/013077.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 06.05.2013 20:36, Eugene Alvin Villar wrote: For those who are not on the tagging mailing list, the wikidata=* tag has been proposed[1], and discussed on the tagging mailing list starting late February 2013[2]. Based on my assessment of the discussion, there doesn't seem to be a clamor to add the wikidata=* tag to replace or even as an additional tag to the wikipedia=* tag. The concern is that wikipedia=* is much more easier for the average mapper to grasp than the wikidata=* tag. I'm subscribed to tagging and aware of that discussion, but it was mostly based on the assumption that one could always get the Wikidata ID indirectly from an Wikipedia article name. That was certainly true back then - during phase 1 of the Wikidata rollout it was merely a new way of storing the links between different Wikipedia languages - and is still essentially true today because the entries were overwhelmingly based on existing Wikipedia content. However, Wikidata's scope is becoming broader. It is intended to replace list articles in Wikipedia and will therefore likely include things that don't have a Wikipedia article on their own. Depending on how the notability politics play out, it may even include items that don't appear on Wikipedia at all. Therefore, there may be a reason to have a wikidata key even if we prefer wikipedia links where they exist. Anyway, most of the thread back then wasn't even about an overlap with the wikipedia key, but about the possibility of replacing/syncing keys such as operator with a wikidata link, which is of course a lot more controversial than the tag in itself. Tobias [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata [2] http://lists.openstreetmap.org/pipermail/tagging/2013-February/013077.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: No, it's not. I did not speak about mapping the hospital and the merchants kontor, but about wikidata entries ahout the hospital and the merchants kontor - and wikidata in fact includes historical entities like that, too. - the merchant's person page (his office) Wikidata would link to their internal building item instead. Not our job imo. - the museum's page Can be linked using the wikidata key at the museum POI. - the restaurant's page Can be linked using the wikidata key at the restaurant POI. You assume here that osm has distinct objects for building, restaurant and museum, but often that's not the case. Let's say the building mainly is/hosts the museum, and the restaurant is a small part of it, covering a part of the building only (may be part of the museum, too. We don't have distinct objects in OSM in every case. Without the restaurant, the museum and the building are the same, identical object; but may be divided later perhaps into two objects (where one changes it's semantics) - the architect's page Can be linked using the architect:wikidata key at the building. Now you introduce a different approach to my overall question, and start to use namespaces for wikidata-tags. So why not in general use namespaces for all (even the cases above): restaurant:wikidata museum:wikidata architect:wikidata fire1934:wikidata merchant:wikidata I think, that get's very verbose once wikidata lifts off, and I don't think it's a good idea. It could be argued that we should leave that to Wikidata, though - they have an architect property for buildings themselves. +1 - the page of the person where the name of the building comes from Can be linked using the name:etymology:wikidata key at the building. Again, we theoretically could omit this and instead rely on Wikidata's named after property. To sum up your arguments: well... let's use foreign keys, but only somewhere. What's the rule you propose for this? when to use the wikidata-tag and when not? Is it possible to describe a rule for this? (even if we don't want to enforce that rule, somehow what you propose should be documented and therefore has to be documentable in a reasonable form). Perhaps look into the overpass-permanent-ID solution for that. In my opinion that's not really a good solution here. Manually creating Overpass API queries is too hard. That's true, but what you propose is (yet) hard, too: To decide where to link to wikidata and where to rely on wikidatas internal links requires deep knowledge about the wikidata system, which is IMHO not acceptable as a general precondition for mappers (whose majority will have to deal with that in future to keep these links reasonably up to date). regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: No, it's not. I did not speak about mapping the hospital and the merchants kontor, but about wikidata entries ahout the hospital and the merchants kontor - and wikidata in fact includes historical entities like that, too. If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. If on the other hand you want to add that hospital and that kontor, then in the historical mapping schema I believe you'd add them as separate objects with their own start_date and end_date tags so that's what would link to wikidata (if you wanted to). - the merchant's person page (his office) Wikidata would link to their internal building item instead. Not our job imo. - the museum's page Can be linked using the wikidata key at the museum POI. - the restaurant's page Can be linked using the wikidata key at the restaurant POI. You assume here that osm has distinct objects for building, restaurant and museum, but often that's not the case. Let's say the building mainly is/hosts the museum, and the restaurant is a small part of it, covering a part of the building only (may be part of the museum, too. If it doesn't occupy the entire building then you can probably add the museum tag on the building geometry but later once you want to add a wikidata tag you'd probably split it out like you'd split a street object when you want to add an attribute that applies to a part of the attribute. If you're into indoor mapping then you'd draw the museum outline separately anyway. Or you could do namespaces, basically using the same criteria as with different attributes. For example opening_hours which may be different for the museum and the building. The mechanism can be the same for wikidata=* as for e.g. opening_hours=* and oneway=*. We don't have distinct objects in OSM in every case. Without the restaurant, the museum and the building are the same, identical object; but may be divided later perhaps into two objects (where one changes it's semantics) - the architect's page Can be linked using the architect:wikidata key at the building. Now you introduce a different approach to my overall question, and start to use namespaces for wikidata-tags. So why not in general use namespaces for all (even the cases above): restaurant:wikidata museum:wikidata architect:wikidata fire1934:wikidata merchant:wikidata I think, that get's very verbose once wikidata lifts off, and I don't think it's a good idea. It could be argued that we should leave that to Wikidata, though - they have an architect property for buildings themselves. +1 - the page of the person where the name of the building comes from Can be linked using the name:etymology:wikidata key at the building. Again, we theoretically could omit this and instead rely on Wikidata's named after property. To sum up your arguments: well... let's use foreign keys, but only somewhere. What's the rule you propose for this? when to use the wikidata-tag and when not? Is it possible to describe a rule for this? (even if we don't want to enforce that rule, somehow what you propose should be documented and therefore has to be documentable in a reasonable form). Perhaps look into the overpass-permanent-ID solution for that. In my opinion that's not really a good solution here. Manually creating Overpass API queries is too hard. That's true, but what you propose is (yet) hard, too: To decide where to link to wikidata and where to rely on wikidatas internal links requires deep knowledge about the wikidata system, which is IMHO not acceptable as a general precondition for mappers (whose majority will have to deal with that in future to keep these links reasonably up to date). Again mappers are already dealing with this problem when they add phone= or website= tags. There's no clear criteria but it's not a a problem specific to wikidata links. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 06.05.2013 23:07, schrieb andrzej zaborowski: Hi, On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: No, it's not. I did not speak about mapping the hospital and the merchants kontor, but about wikidata entries ahout the hospital and the merchants kontor - and wikidata in fact includes historical entities like that, too. If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. Why not? The building is the same, and it's not of interest, that the tag amenity=museum is not (any more) existent in osm. If that's an argument any wikidata entity that's not tagged as complete as the wikidata entity itself would be nothing to be linked. Your cross-reference (only add a reference osm pointing to wikidata to the building, but link all other entities of wikidata to the building) argument may be valid, but it's complex (that's my question below); but especially historical entities are of interest to be linked, as they are not directly findable by going out and watch. [...] - the restaurant's page Can be linked using the wikidata key at the restaurant POI. You assume here that osm has distinct objects for building, restaurant and museum, but often that's not the case. Let's say the building mainly is/hosts the museum, and the restaurant is a small part of it, covering a part of the building only (may be part of the museum, too. If it doesn't occupy the entire building then you can probably add the museum tag on the building geometry but later once you want to add a wikidata tag you'd probably split it out like you'd split a street object when you want to add an attribute that applies to a part of the attribute. If you're into indoor mapping then you'd draw the museum outline separately anyway. so you propose to split it up because of an external ID you propose to add... While I in general agree that objects of osm are split when they get mapped in more detail (like in this example), I'm not happy to do that for the reason to enable matching to external references. Or you could do namespaces, basically using the same criteria as with different attributes. For example opening_hours which may be different for the museum and the building. The mechanism can be the same for wikidata=* as for e.g. opening_hours=* and oneway=*. and it's not working for opening_hours either afaik; usually we split the pois in these cases. [...] Perhaps look into the overpass-permanent-ID solution for that. In my opinion that's not really a good solution here. Manually creating Overpass API queries is too hard. That's true, but what you propose is (yet) hard, too: To decide where to link to wikidata and where to rely on wikidatas internal links requires deep knowledge about the wikidata system, which is IMHO not acceptable as a general precondition for mappers (whose majority will have to deal with that in future to keep these links reasonably up to date). Again mappers are already dealing with this problem when they add phone= or website= tags. There's no clear criteria but it's not a a problem specific to wikidata links. Of course not, but even the external id problem is not specific to wikidata links. Wikipedia links are for a long time relatively stable, and as wikipedia I think is often used as one reference for osm, too, it's widely accepted to be of benefit for both sides. Wikidata is not yet proven that stable nor that useful, and - especially: it's a data project. It would be a great task and solution to design e.g. an overpass-permanent-osm-id-editor that defines the link in a useful gui (e.g. derived from wikidata attributes like country, county, city, postcode, location/coordinate, address, ... which might be part of wikidata, I think. Wikidata links are harder to maintain, nearly impossible to check (without opening the page), while wikipedia links have meaningful names. Wikidata links currently are mostly duplicates of wikipedia article's entities (as that's the big imported stuff from the beginning). Therefore I personally oppose currently to reference wikidata entities from osm objects; at least where no good rules exist where and when to link which types of objects, and which not. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, I also think that linking from an OSM object to a growing no. of external databases (incl. Wikipedia/Wikidata) is not a good idea. And I respect the wish of the OSM maintainers to change the OSM id in the future. But the overpass-permanent-osm-id is no solution neither, primo because a set of key-values is a clumsy id, and secondo because there exist many OSM objects which have no identifying tags (or none at all). As this issue pops up from in increasingly frequent intervals I think it's time to think about a good mid term solution (short term is sticking to the OSM id). I'm proposing a solution alongside one of the following two directions: * either to implement a Linked Data API/service which maps from permanent ids to OSM objects (and which is what I like about overpass - being a service) - * or to add a permanent id as an additional XML tag to every OSM object! And if somebody thinks that's a waste of space we can easily drop the XML tag user which is completely redundant to uid (which in turn needs another simple API to find out the current users display name). Yours, Stefan 2013/5/6 Peter Wendorff wendo...@uni-paderborn.de: Am 06.05.2013 23:07, schrieb andrzej zaborowski: Hi, On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 06.05.2013 20:26, schrieb Tobias Knerr: On 06.05.2013 18:54, Peter Wendorff wrote: [...] Let's see this example: A building that was a merchants kontor a few hundret years ago, and now contains a museum and a restaurant, while in between it was - let's say - a hospital). That's historical mapping. The problems would be the same for e.g. the name. But as for the parts of the example that are not directly historic: No, it's not. I did not speak about mapping the hospital and the merchants kontor, but about wikidata entries ahout the hospital and the merchants kontor - and wikidata in fact includes historical entities like that, too. If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. Why not? The building is the same, and it's not of interest, that the tag amenity=museum is not (any more) existent in osm. If that's an argument any wikidata entity that's not tagged as complete as the wikidata entity itself would be nothing to be linked. Your cross-reference (only add a reference osm pointing to wikidata to the building, but link all other entities of wikidata to the building) argument may be valid, but it's complex (that's my question below); but especially historical entities are of interest to be linked, as they are not directly findable by going out and watch. [...] - the restaurant's page Can be linked using the wikidata key at the restaurant POI. You assume here that osm has distinct objects for building, restaurant and museum, but often that's not the case. Let's say the building mainly is/hosts the museum, and the restaurant is a small part of it, covering a part of the building only (may be part of the museum, too. If it doesn't occupy the entire building then you can probably add the museum tag on the building geometry but later once you want to add a wikidata tag you'd probably split it out like you'd split a street object when you want to add an attribute that applies to a part of the attribute. If you're into indoor mapping then you'd draw the museum outline separately anyway. so you propose to split it up because of an external ID you propose to add... While I in general agree that objects of osm are split when they get mapped in more detail (like in this example), I'm not happy to do that for the reason to enable matching to external references. Or you could do namespaces, basically using the same criteria as with different attributes. For example opening_hours which may be different for the museum and the building. The mechanism can be the same for wikidata=* as for e.g. opening_hours=* and oneway=*. and it's not working for opening_hours either afaik; usually we split the pois in these cases. [...] Perhaps look into the overpass-permanent-ID solution for that. In my opinion that's not really a good solution here. Manually creating Overpass API queries is too hard. That's true, but what you propose is (yet) hard, too: To decide where to link to wikidata and where to rely on wikidatas internal links requires deep knowledge about the wikidata system, which is IMHO not acceptable as a general precondition for mappers (whose majority will have to deal with that in future to keep these links reasonably up to date). Again mappers are already dealing with this problem when they add phone= or website= tags. There's no clear criteria but it's not a a problem specific to wikidata links. Of course not, but even the external id problem is not specific to wikidata links. Wikipedia links are for a long time
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 06.05.2013 23:55, schrieb Peter Wendorff: Am 06.05.2013 23:07, schrieb andrzej zaborowski: If you're not adding those historical entities to OSM (or a similar database like that historical osm once discussed) then there's no issue with linking to Wikidata because there's nothing to be linked. Why not? It wouldn't add any information. The hospital should be linked to the building _within_ Wikidata anyway because there are more properties that can be attached to a building than just a OSM building outline. So if we connect the OSM building and the Wikidata building, then the hospital is already (though Wikidata) linked to the OSM building, too. If it doesn't occupy the entire building then you can probably add the museum tag on the building geometry but later once you want to add a wikidata tag you'd probably split it out like you'd split a street object when you want to add an attribute that applies to a part of the attribute. If you're into indoor mapping then you'd draw the museum outline separately anyway. so you propose to split it up because of an external ID you propose to add... While I in general agree that objects of osm are split when they get mapped in more detail (like in this example), I'm not happy to do that for the reason to enable matching to external references. Using the same OSM element for two distinct features actually contradicts a strict one feature, one OSM element principle. We do it anyway because it's convenient, but as soon as you want to add the same tag - whether it's name, opening_hours, or wikidata - to both features, you create two separate elements. That's not a special treatment of external IDs, but consistent with other tags, and using two separate elements is semantically better anyway. and it's not working for opening_hours either afaik; usually we split the pois in these cases. Exactly. Wikidata links are harder to maintain, nearly impossible to check (without opening the page), while wikipedia links have meaningful names. YMMV, but I always open Wikipedia links to check whether they are (still) correct. Therefore I personally oppose currently to reference wikidata entities from osm objects; at least where no good rules exist where and when to link which types of objects, and which not. I think a good rule to start with would be: If there is a Wikipedia or Wikidata entry about that particular feature *itself*, then it can always be linked (using the appropriate key). Such links cannot possibly be replaced with links within Wikidata, and there is a limited number of them. With the namespaced links, however, we indeed get an essentially unbounded number of potential links and I don't know a good rule for these atm. Tobias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hello Andreas, I hope Wikidata part 3 solve the problem with the list, so that an object would be one Wikidata entry and can be a member in different lists but can also have an own article. A map with objects in the example article is here:[1] I have no influence on the way how http://www.openstreetmap.org/browse/way/48434939 links to Wikipedia, I could also only ask an admin. With a link to index.php it would be easy to solve[2]. An external project with m:n-relations between OSM and WP would have it's own problems. Greetings Tim alias Kolossos [1]http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=deuselang=detitle=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte%20in%20Wien%2FPenzingzoom=15lat=48.21428lon=16.22318layers=B00FFTTF [2]http://de.wikipedia.org/w/index.php?uselang=detitle=Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25026 Am 05.05.2013 08:08, schrieb Andreas Labres: Tim, There are problems with WIWOSM that aren't solved at all... Example: Historic monuments in Austria. They are all covered in Wikipedia, but mostly only in Lists. And they do have a distinguishable objectID, but I can't really state this in OSM. For instance: http://www.openstreetmap.org/browse/way/207854465 ist such a historic monument with objectID 25020. It can be found in Wikipedia here: http://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25020 So I can only state the tag wikipedia:de = Liste der denkmalgeschützten Objekte in Wien/Penzing#objektid-25020 This has the effect that the link in OSM doesn't work (because OSM adds a userlang parameter behind the anchor reference which I consider a bug of OSM [did already report it]). And also WIWOSM can't reference the distict object. Though it seems to be able to reference some of the Liste_der_denkmalgeschützten_Objekte_in_Wien/Penzing. It can't do all because some of the objects do have their own wikipedia entrance, for instance Mariarunn church: http://www.openstreetmap.org/browse/way/48434703 http://de.wikipedia.org/wiki/Pfarr-_und_Wallfahrtskirche_Mariabrunn So what would be necessary is that wikipedia and OSM would agree on some kind of generic ID, which could in the case of historic monuments in Austria be some /monument/AT/$objectID, e.g. /monument/AT/25020, which then would redirect to http://de.wikipedia.org/wiki/Liste_der_denkmalgesch%C3%BCtzten_Objekte_in_Wien/Penzing#objektid-25020 whereas /monument/AT/24616 could redirect to http://de.wikipedia.org/wiki/Pfarr-_und_Wallfahrtskirche_Mariabrunn /al ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Tim, There are different problems, let's keep them separate (vielleicht reden wir auch - Englisch - aneinander vorbei... ;) a) There is a problem in the code of osm.org how it links wikipedia articles. You can't do a link like this: $PATH#anchor?uselang=en This is bad URL syntax. You (osm.org) have to do $PATH?uselang=en#anchor https://trac.openstreetmap.org/ticket/4802 b) It is not a good idea to link objects in Wikipedia lists like Liste der denkmalgeschützten Objekte in Wien/Penzing#objektid-25026 This object should have its own name in Wikipedia, which then redirects to whereever this object can be found. This shouldn't be external but a feature in Wikipedia/Wikidata/Wikiwhatsoever. c) The objectID I'm referencing is nothing external, it's a nationally unique ID given by the Austrian Bundesdenkmalamt which identifies each monument in Austria. Therefore it's the best idea to use /this/ as /the/ reference to the given object (with reference to it being a historic monument). Alex Wagner, who created all the Denkmalgeschützte Objekte in Austria in the Wikipedia used it when he created the Wikipedia pages. http://lists.openstreetmap.org/pipermail/talk-at/2013-April/005542.html ff OSM could save this objectID, say: ref:monument=AT:25026 and WIWOSM then knows how to find this (uniquely identified) object in Wikipedia. /al ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi guys, I am most likely the one who started the whole issue of adding relation IDs to Wikipedia at all - I created the Wikipedia templates and inserted several tenths of relation IDs to specific articles... and you know why? Because at the time I did that there was no WIWOSM (or any other usable tool for featuring OSM content within Wikimedia projects) and this was the easiest (although I understand not the best) way to connect/link Wikipedia to OSM. I understand tag query for a specific keywors(s) (probably deriving from Wikipedia article name) would be much better, there simply WAS NOT a simple enough tool to do this or at least I did not know about such a tool. The original idea was to link a page that would show a desired object in a map. So the action definitely was simply a result of lack of services on OSM side. If this has changed now, I suggest we use such a tool that produces similar output (in terms of data and speed) as the current relations links. Regards, Kozuch 2013/5/5 Andreas Labres l...@lab.at Tim, There are different problems, let's keep them separate (vielleicht reden wir auch - Englisch - aneinander vorbei... ;) a) There is a problem in the code of osm.org how it links wikipedia articles. You can't do a link like this: $PATH#anchor?uselang=en This is bad URL syntax. You (osm.org) have to do $PATH?uselang=en#anchor https://trac.openstreetmap.org/ticket/4802 b) It is not a good idea to link objects in Wikipedia lists like Liste der denkmalgeschützten Objekte in Wien/Penzing#objektid-25026 This object should have its own name in Wikipedia, which then redirects to whereever this object can be found. This shouldn't be external but a feature in Wikipedia/Wikidata/Wikiwhatsoever. c) The objectID I'm referencing is nothing external, it's a nationally unique ID given by the Austrian Bundesdenkmalamt which identifies each monument in Austria. Therefore it's the best idea to use /this/ as /the/ reference to the given object (with reference to it being a historic monument). Alex Wagner, who created all the Denkmalgeschützte Objekte in Austria in the Wikipedia used it when he created the Wikipedia pages. http://lists.openstreetmap.org/pipermail/talk-at/2013-April/005542.html ff OSM could save this objectID, say: ref:monument=AT:25026 and WIWOSM then knows how to find this (uniquely identified) object in Wikipedia. /al ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
[Quoting repaired on an (as it seems) accidential PM] yve...@gmail.com wrote on Sun, 05 May 2013 08:53:04: malenki wrote On 04.05.2013 15:24, Paul Norman wrote: When I get new imagery for the area and re-trace the building depending on what is easiest I may end up creating a new way. The tool replace geometry exists - at least for JOSM. It even works on replacing an old (existing) Node for a new way. Josm is an editor, it's not concerned in affecting IDs at all. That's the API job. When you delete any object using any editor, the IDs are insofar affected as the object the ID points to is marked as deleted. Don't know if you are happy with a valid ID pointing to nowhere. ;) Using replace geometry you can re-trace your building, mark both old and new way and apply the tool so the old way with its nodes gets the shape of the new way but keeps its and the nodes old IDs. Regards malenki ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Jason Remillard remillard.ja...@gmail.com wrote: However, given what exists today shouldn't Wikipedia be using the overpass API for referencing OSM? I'd also say so: There already is a Permanent ID [1] service. http://overpass-api.de/api/interpreter?data=[out:custom];rel[boundary=administrative][admin_level=6][name=London];out; Regards, Martin / tyr_asd [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote: Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. Wikipedia URLs are themselves potentially unstable, though - it's usually more or less okay for geographic places, since we tend to have fixed naming systems, but to pick a high-profile example, the URL https://en.wikipedia.org/wiki/Perth has at various times over the past ten years pointed to Perth in Perthshire, Perth in Western Australia, and a placeholder disambiguator page. (They are also, of course, language-dependent, but that's another kettle of fish) Wikidata entities are (with a few caveats) static and language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and could potentially be useful here - but they're not human-readable and you'd have to rely on an API to convert them into page titles, which seems like it might not be desirable. -- - Andrew Gray andrew.g...@dunelm.org.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, Wikidata entities are (with a few caveats) static and language-independent (eg https://www.wikidata.org/wiki/Q3183), and could potentially be useful here I totally agree, so tagging OSM entities with Wikidata IDs (where applicable) might improve the stability even beyond that of using Wikipedia arctile names. but they're not human-readable and you'd have to rely on an API to convert them into page titles, which seems like it might not be desirable. We are talking about people wanting stable references to OSM. If this is the most stable way to do, then ppl have to - and will - live with it. Because they are doing it already. Right now, [1] is a popular source for stable identifiers - for each Wikipedia article, there a a corresponding *machine readable* DBpedia entry [2]. And in [3] you see an overview of datasets referring to these IDs. Note that by ID I actually mean IRIs in general. So if Wikidata succeeds, we will be using their IDs all over the place. There is work in progress to make Wikidata Linked Data / Semantic Web compatible - in the next few months we will know more[4]. As for the Demo I meantioned in another mail: I am the maintainer of the LinkedGeoData (LGD)[5] project where we publish the whole OSM database as RDF data. This means I have a full, live synced replicate of the planet here - and let me say great job! to the osmosis devs :) So I created a Wikipedia article name Linked Data API: Note that there are just a bit more than 100K entities having a wikipedia tag, and the data quality seems really low. http://test.linkedgeodata.org/wp/Catford This does a lookup for the OSM id based on their wikipedia and wikipedia:en tags. When you follow the shown sameAs link, you will go to: http://test.linkedgeodata.org/triplify/node13878144 which is the RDF version of the corresponding OSM entity. Yay! Note, at this URL, you will see that it points to http://dbpedia.org/resource/Catford - so you can navigate the *data* just like hyperlinks in HTML documents. Also note, that this is not just a I hack a REST API thing: You can also query it - e.g. whiche user added the Wikipedia link and what else did he edit: bit.ly/13chv0W http://bit.ly/13chv0W Add 'Explain' before the 'SELECT' to see the SQL. Yes, its a bit slow because Postgres takes a bad query plan for the conditional Wikipedia tags index _. Everything will get better with the new materialized views support ;) Cheers, Claus [1] http://dbpedia.org [2] Example: http://dbpedia.org/resource/Catford Note:If you start scraping the HTML for data, you're doing it wrong ;) curl -LH Accept: application/rdf+xml http://dbpedia.org/resource/Catford curl -LH Accept: application/json http://dbpedia.org/resource/Catford Or visit: http://dbpedia.org/data/Catford.ntriples Same data, different formats. [3] http://lod-cloud.net/versions/2011-09-19/lod-cloud_colored.html [4] http://meta.wikimedia.org/wiki/Wikidata/Development/RDF [5] http://linkedgeodata On 05/04/2013 11:47 AM, Andrew Gray wrote: On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote: Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. Wikipedia URLs are themselves potentially unstable, though - it's usually more or less okay for geographic places, since we tend to have fixed naming systems, but to pick a high-profile example, the URL https://en.wikipedia.org/wiki/Perth has at various times over the past ten years pointed to Perth in Perthshire, Perth in Western Australia, and a placeholder disambiguator page. (They are also, of course, language-dependent, but that's another kettle of fish) Wikidata entities are (with a few caveats) static and language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and could potentially be useful here - but they're not human-readable and you'd have to rely on an API to convert them into page titles, which seems like it might not be desirable. -- Dipl. Inf. Claus Stadler Department of Computer Science, University of Leipzig Research Group: http://aksw.org/ Workpage WebID: http://aksw.org/ClausStadler Phone: +49 341 97-32260 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 4 May 2013, at 10:47, Andrew Gray andrew.g...@dunelm.org.uk wrote: On 4 May 2013 00:49, Claus Stadler cstad...@informatik.uni-leipzig.de wrote: Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. Wikipedia URLs are themselves potentially unstable, though - it's usually more or less okay for geographic places, since we tend to have fixed naming systems, but to pick a high-profile example, the URL https://en.wikipedia.org/wiki/Perth has at various times over the past ten years pointed to Perth in Perthshire, Perth in Western Australia, and a placeholder disambiguator page. (They are also, of course, language-dependent, but that's another kettle of fish) Being language dependant isn't as issue as you simply state the language of the article name used, and then through interwiki links can link to the appropriate article in any wikipedia language. Shaun Wikidata entities are (with a few caveats) static and language-independent (eg https://www.wikidata.org/wiki/Q3183 ), and could potentially be useful here - but they're not human-readable and you'd have to rely on an API to convert them into page titles, which seems like it might not be desirable. -- - Andrew Gray andrew.g...@dunelm.org.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hello, as co-creator of WIWOSM I was also against this Wikidata-property, but I came too late. WIWOSM links are not only more stable and human-readable, the are also much more flexible. So in WIWOSM we can suport relations but also multirelations, ways, multiways nodes, multinodes. I'm waiting for the day where the people starts to create relations for each building only to be able to link on it from Wikidata. We have now Wikipedia-Tags for over 300.000 objects and I would prefer to concentrate the power of the community to one system instead to split it. In my eyes, what Wikidata perhaps need is one bit (created by a bot) with the information yes there is an matching OSM object to create a link to a map, the rest can come from WIWOSM. Later if Wikidata starts to have entries without an own Wikipedia-article we should support a Wikidata-Tag, but thats on way[2]. This will happen at part 3 of Wikidata-project were they want to support list creation. With projects like WikiLovesMonuments I'm sure that we will have on some places a link for each building, so the problem above is not only theory. Greetings Tim alias Kolossos [1] http://taginfo.openstreetmap.org/keys/wikipedia [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata Am 04.05.2013 01:49, schrieb Claus Stadler: Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. Cheers, Claus On 05/04/2013 01:34 AM, Jason Remillard wrote: Hi, In general is seems like it might be useful to have some kind of somewhat permanent URL to an element inside of OSM. However, given what exists today shouldn't Wikipedia be using the overpass API for referencing OSM? Thanks Jason. On Fri, May 3, 2013 at 6:46 PM, Paul Norman penor...@mac.com wrote: From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Friday, May 03, 2013 2:08 PM To: Frederik Ramm Cc: OpenStreetMap Subject: Re: [OSM-talk] OSM relation ID property in Wikidata I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. There's two sides to ID stability. One is stability during software or data model changes and the other is stability during normal mapping. Frederik's post was concerned more with the former. The latter is more complicated. Because the original message linked to London, it's worth pointing out that a few admin relations did get new IDs in the redaction process for technical reasons and that periodically relations get given new IDs because old large complex relations don't interact well with the /history call. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. But, what is the point if ID's are not stable? How can we externally link to the data and make sure link will stay valid in time? I am not talking about URL links but links to objects (which, obviously, is done by object ID). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
From: Mike [mailto:mike.cuttl...@gmail.com] Sent: Saturday, May 04, 2013 1:36 PM To: talk@openstreetmap.org Subject: Re: [OSM-talk] OSM relation ID property in Wikidata I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. But, what is the point if ID's are not stable? How can we externally link to the data and make sure link will stay valid in time? I am not talking about URL links but links to objects (which, obviously, is done by object ID). A link to an OSM object will remain a link to an OSM object, but that's not very helpful. An OSM ID will normally correspond to the same physical object for all of its versions, unless its deleted. There is no guarantee, but it allows you to say that if node 123 is not deleted then it is probably Joe's coffee shop. It doesn't allow you to say that Joe's coffee shop is node 123. A physical object will not always correspond to the same OSM ID. It is this last property that matters for external links. As an example, a particular Lowe's home improvement store near me used to be OSM node 1498097430 and now is OSM way 136961700. When I get new imagery for the area and re-trace the building depending on what is easiest I may end up creating a new way. Relying on the OSM representation of some real-world object to maintain the same ID is wrong. There is no property of OSM IDs that allows you to say that Joe's coffee shop will continue to be node 123. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 04.05.2013 15:24, Paul Norman wrote: When I get new imagery for the area and re-trace the building depending on what is easiest I may end up creating a new way. The tool replace geometry exists - at least for JOSM. It even works on replacing an old (existing) Node for a new way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM relation ID property in Wikidata
Hi. Just wanted to notify those who didn't know: There is now a property (P402) in use in Wikidata to link the corresponding entry to a relation ID in OSM. Example: https://www.wikidata.org/wiki/Q84 With regards, Svavar Kjarrval signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, On 03.05.2013 18:15, Svavar Kjarrval wrote: Just wanted to notify those who didn't know: There is now a property (P402) in use in Wikidata to link the corresponding entry to a relation ID in OSM. This is a very bad idea and should not be used. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On Sat, May 4, 2013 at 3:33 AM, Frederik Ramm frede...@remote.org wrote: On 03.05.2013 18:15, Svavar Kjarrval wrote: Just wanted to notify those who didn't know: There is now a property (P402) in use in Wikidata to link the corresponding entry to a relation ID in OSM. This is a very bad idea and should not be used. I assume you think this is bad because OSM IDs are not stable with respect to the objects they represent? It seems this was discussed by the Wikidata users when there was a very recent proposal to delete this OSM ID property (P402): https://www.wikidata.org/wiki/Wikidata:Properties_for_deletion#Property:P402 The consensus was that--at least for place relations which are the target of the said property--OSM relation IDs are stable enough and any changes in IDs can be easily rectified. Wikidata is a wiki after all. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, On 03.05.2013 22:12, Eugene Alvin Villar wrote: The consensus was that--at least for place relations which are the target of the said property--OSM relation IDs are stable enough and any changes in IDs can be easily rectified. Wikidata is a wiki after all. I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. I fear that some day soon we'll have a good idea about re-organising our admin bounds that involves large-scale changes, and then people come to us and say ah, that's unfortunate because we at [insert some other project or product or company] had assumed that relation IDs are relatively stable As soon as everyone who uses our relation IDs as external pointers signs a document that says I know I am doing something that could potentially backfire and if it does I swear that I will not try to exert pressure on OSM but instead tell my own users that it is entirely my fault for being short-sighted and that I had been warned, then I guess that's fine ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote: On 03.05.2013 22:12, Eugene Alvin Villar wrote: The consensus was that--at least for place relations which are the target of the said property--OSM relation IDs are stable enough and any changes in IDs can be easily rectified. Wikidata is a wiki after all. I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, On 03.05.2013 23:08, andrzej zaborowski wrote: The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. The OSMF has never sent messages saying that object IDs are stable or even stable enough for anything; if you interpreted any of the license change discussions in that way, you are mis-interpreting them. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On Fri, May 03, 2013 at 11:08:01PM +0200, andrzej zaborowski wrote: On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote: On 03.05.2013 22:12, Eugene Alvin Villar wrote: The consensus was that--at least for place relations which are the target of the said property--OSM relation IDs are stable enough and any changes in IDs can be easily rectified. Wikidata is a wiki after all. I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. What are you talking about? Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 3 May 2013 23:14, Frederik Ramm frede...@remote.org wrote: On 03.05.2013 23:08, andrzej zaborowski wrote: The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. The OSMF has never sent messages saying that object IDs are stable or even stable enough for anything; if you interpreted any of the license change discussions in that way, you are mis-interpreting them. I don't understand -- wasn't the entire process based on the assumption that intellectual property persists as long as the object ID persists? Wasn't that in part your own decision? Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, On 03.05.2013 23:18, andrzej zaborowski wrote: I don't understand -- wasn't the entire process based on the assumption that intellectual property persists as long as the object ID persists? No, that is a misconception. During the license change we deviated from that idea in both directions: * some objects whose ID had not changed and who had been created by someone who rejected the license were nonetheless kept if it could be shown that they had been changed in a major way since; * some objects that had been freshly created by people agreeing with the license change, but that were more or less copies of other objects from non-agreers, were removed even though they had a different ID. I will not discuss this sub-thread further; object IDs are not stable and nothing we did during the license change is suitable as a counter argument. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Am 03.05.2013 23:08, schrieb andrzej zaborowski: On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote: On 03.05.2013 22:12, Eugene Alvin Villar wrote: The consensus was that--at least for place relations which are the target of the said property--OSM relation IDs are stable enough and any changes in IDs can be easily rectified. Wikidata is a wiki after all. I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. There are two sides of stable. Of course a node created with id 123 will always have id 123. But the tags of the node could change. So node 123 could be a restaurant in v1 and in v2 a node in a highway. So if you have a restaurant-DB pointing to node 123 would fail Henning ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
On 3 May 2013 23:22, Frederik Ramm frede...@remote.org wrote: * some objects whose ID had not changed and who had been created by someone who rejected the license were nonetheless kept if it could be shown that they had been changed in a major way since; * some objects that had been freshly created by people agreeing with the license change, but that were more or less copies of other objects from non-agreers, were removed even though they had a different ID. The redaction bot code doesn't generally do that and if there were such cases then they were an insignificant minority compared to those where the change of the object's ID meant it was considered an entirely different object. It's strange that you'd negate that. I will not discuss this sub-thread further; object IDs are not stable and nothing we did during the license change is suitable as a counter argument. The fact that the IDs are not persistent had been pointed out several times during the process and both you and the LWG have said (this is quite clearly stated their meeting minutes) that this isn't an issue big enough to bother. There were some statistics posted on the list and on IRC (from Simon Poole) stating it affected 0.1 to 1% of the database which is in the millions of objects range. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Friday, May 03, 2013 2:08 PM To: Frederik Ramm Cc: OpenStreetMap Subject: Re: [OSM-talk] OSM relation ID property in Wikidata I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. There's two sides to ID stability. One is stability during software or data model changes and the other is stability during normal mapping. Frederik's post was concerned more with the former. The latter is more complicated. Because the original message linked to London, it's worth pointing out that a few admin relations did get new IDs in the redaction process for technical reasons and that periodically relations get given new IDs because old large complex relations don't interact well with the /history call. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Hi, In general is seems like it might be useful to have some kind of somewhat permanent URL to an element inside of OSM. However, given what exists today shouldn't Wikipedia be using the overpass API for referencing OSM? Thanks Jason. On Fri, May 3, 2013 at 6:46 PM, Paul Norman penor...@mac.com wrote: From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Friday, May 03, 2013 2:08 PM To: Frederik Ramm Cc: OpenStreetMap Subject: Re: [OSM-talk] OSM relation ID property in Wikidata I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay (IDs are stable enough), this will put pressure on *us* and limit our flexibility in the future. The OSMF has sent a pretty strong message saying that object IDs are stable enough to base impactful legal decisions on them. It will look silly for them to go back to the stance that IDs aren't stable after all. There's two sides to ID stability. One is stability during software or data model changes and the other is stability during normal mapping. Frederik's post was concerned more with the former. The latter is more complicated. Because the original message linked to London, it's worth pointing out that a few admin relations did get new IDs in the redaction process for technical reasons and that periodically relations get given new IDs because old large complex relations don't interact well with the /history call. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
2013/5/4 Claus Stadler cstad...@informatik.uni-leipzig.de Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. there are also other tags to point from certain OSM attributes to wikipedia, e.g. http://taginfo.openstreetmap.org/keys/wikipedia%3Aoperatorand http://taginfo.openstreetmap.org/keys/operator%3Awikipedia but isn't this thread about pointing from outside to osm? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
Isn't this thread about pointing from outside to osm? Yes, so the simple suggestion is for OSM to extend the API to expose the wiki tags; something like Something along the lines of: http://www.openstreetmap.org/api/0.6/wiki/{lang}/{article} And this would return the corresponding object(s). Even better, if it was Linked Data API in the first place [1] ;) Give me a bit and I can demonstrate (I need to recreate the index on the node_tags column _) ;) Cheers, Claus [1] http://www.w3.org/DesignIssues/LinkedData.html On 05/04/2013 01:58 AM, Martin Koppenhoefer wrote: 2013/5/4 Claus Stadler cstad...@informatik.uni-leipzig.de mailto:cstad...@informatik.uni-leipzig.de Hi, Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than Wikipedia referring to database identifiers? (The answer is a clear 'yes' from my side.) In fact there are the (wikipedia, *) tags - but not sure how good the quality is - what can be seen on a first glance is, that people mix URLs and article names, and also encoding. there are also other tags to point from certain OSM attributes to wikipedia, e.g. http://taginfo.openstreetmap.org/keys/wikipedia%3Aoperator and http://taginfo.openstreetmap.org/keys/operator%3Awikipedia but isn't this thread about pointing from outside to osm? cheers, Martin -- Dipl. Inf. Claus Stadler Department of Computer Science, University of Leipzig Research Group: http://aksw.org/ Workpage WebID: http://aksw.org/ClausStadler Phone: +49 341 97-32260 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM US Edit-a-thon April 20-21
Hello OSMers world-wide, Firstly, a reminder that OSM US is hosting an Edit--a-thon APril 20-21; info at http://www.openstreetmap.us/2013/03/april-spring-editathon/ Please join with your US colleagues and help improve the US map ! I am also wondering if any OSM server maintenance is anticipated or being planned for that weekend. Best Regards, -- John Novak 585-OLD-TOPOS (585-653-8676) http://www.linkedin.com/in/johnanovak/ OSM ID:oldtopos OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Fwd: [OSM-talk] OSM Monster
Il 30/03/2013 18:42, Martin Koppenhoefer ha scritto: scusate il cross-posting, ma è troppo bello ;-) ciao, Martin Filmato interessante, con tema dominante l'ingordigia:-) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk] OSM DB down for maintenance
I noticed that the database is down for maintenance this morning. I couldn't find any announcement for this downtime so it sounds like it was unplanned. Can anyone shed any light on what is going on, and when it is likely to be back up again? Thanks! Colin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM DB down for maintenance
Hi it seems that the Server Ramoth http://wiki.openstreetmap.org/wiki/Servers/ramoth is unresponsive and couldn't be rebooted remotely. Some admins are on-site (or on their way) to give it a kick. In the meantime it seems everything's up again, but it could be that another restart is required until all services work properly again. Peter Am 31.03.2013 12:30, schrieb Colin Smale: I noticed that the database is down for maintenance this morning. I couldn't find any announcement for this downtime so it sounds like it was unplanned. Can anyone shed any light on what is going on, and when it is likely to be back up again? Thanks! Colin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM DB down for maintenance
On 31/03/13 11:40, Peter Körner wrote: it seems that the Server Ramoth http://wiki.openstreetmap.org/wiki/Servers/ramoth is unresponsive and couldn't be rebooted remotely. Some admins are on-site (or on their way) to give it a kick. In the meantime it seems everything's up again, but it could be that another restart is required until all services work properly again. Nobody is on their way anywhere actually... We won't be able to get access to the site until Tuesday. I have got things up and running in read-only mode now against a backup machine, and that is probably how things are going to have to remain for the next couple of days. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM DB down for maintenance
Nobody is on their way anywhere actually... We won't be able to get access to the site until Tuesday. Tom, is this due to the current holiday, and lack of access to the facility (UCL or Imperial?)? Or are admins unavailable, on holiday? -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Tom Hughes t...@compton.nu To: Peter Körner osm-li...@mazdermind.de Cc: talk@openstreetmap.org Sent: Sunday, March 31, 2013 7:25 AM Subject: Re: [OSM-talk] OSM DB down for maintenance On 31/03/13 11:40, Peter Körner wrote: it seems that the Server Ramoth http://wiki.openstreetmap.org/wiki/Servers/ramoth is unresponsive and couldn't be rebooted remotely. Some admins are on-site (or on their way) to give it a kick. In the meantime it seems everything's up again, but it could be that another restart is required until all services work properly again. Nobody is on their way anywhere actually... We won't be able to get access to the site until Tuesday. I have got things up and running in read-only mode now against a backup machine, and that is probably how things are going to have to remain for the next couple of days. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM DB down for maintenance
All up and running again. Replaced a raid controller. Regards Grant OpenStreetMap sysadmin team On 31 Mar 2013 11:30, Colin Smale colin.sm...@xs4all.nl wrote: ** I noticed that the database is down for maintenance this morning. I couldn't find any announcement for this downtime so it sounds like it was unplanned. Can anyone shed any light on what is going on, and when it is likely to be back up again? Thanks! Colin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM DB down for maintenance
The OSM community owes you, Grant and the other sysadmins, a lot of gratitude for your work to maximize availability. Thanks! Cheers, Johan (user: It's so funny) 2013/3/31 Grant Slater openstreet...@firefishy.com All up and running again. Replaced a raid controller. Regards Grant OpenStreetMap sysadmin team On 31 Mar 2013 11:30, Colin Smale colin.sm...@xs4all.nl wrote: ** I noticed that the database is down for maintenance this morning. I couldn't find any announcement for this downtime so it sounds like it was unplanned. Can anyone shed any light on what is going on, and when it is likely to be back up again? Thanks! Colin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Fwd: [OSM-talk] OSM Monster
noto qualche problema di licenza :) --- All the vector map data used in this film is (c) OpenStreetMaps and its contributors, and is licensed under a Creative Commons license, just like the film itself. --- Tra l'altro il film finisce dichiarando di essere in cc-by-nc-sa e che i dati sono in cc-by-sa Insomma: un po' di confusione :) Ho lasciato un commento, vediamo se si arrabbiano On Sat, Mar 30, 2013 at 6:42 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: scusate il cross-posting, ma è troppo bello ;-) ciao, Martin -- Forwarded message -- From: Martijn van Exel m...@rtijn.org Date: 2013/3/30 Subject: [OSM-talk] OSM Monster To: OSM Talk t...@openstreetmap.org OSM data turned into a monster! http://vimeo.com/62468031 -- Martijn van Exel ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [OSM-talk] OSM Monster
Il 30/03/2013 20:57, Simone Saviolo ha scritto: Molto bello! Peccato che abbia scelto uno stile di mappa che ricorda molto GMaps... :-) Ciao, Simone +1 Inoltre all'inizio sembra che usino streetview... -- Google riceve multa da sette milioni di dollari per aver raccolto dati personali senza autorizzazione tramite street view. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk] OSM Monster
OSM data turned into a monster! http://vimeo.com/62468031 -- Martijn van Exel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-it] Fwd: [OSM-talk] OSM Monster
scusate il cross-posting, ma è troppo bello ;-) ciao, Martin -- Forwarded message -- From: Martijn van Exel m...@rtijn.org Date: 2013/3/30 Subject: [OSM-talk] OSM Monster To: OSM Talk t...@openstreetmap.org OSM data turned into a monster! http://vimeo.com/62468031 -- Martijn van Exel __**_ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [OSM-talk] OSM Monster
Molto bello! Peccato che abbia scelto uno stile di mappa che ricorda molto GMaps... :-) Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] [osm-fr CA] Fwd: UAV Drone and OSM
Le 12 févr. 2013 à 15:08, Guillaume Allegre a écrit : Le mar. 12 fevr. 2013 à 10:37 +0300, Fred Moine a ecrit : Apres sur place, j’ai ma nièce qui peut heberger ou laisser son appartement pour le week end. Ou sinon elle a des copines de 20 a 29 ans super canon. Je vais faire mon rabat-joie. J'aimerais beaucoup ne plus voir de remarques sexistes sur cette liste à l'avenir. J'aimerais, que sur cette liste, on ne voit pas du sexisme, là où il n'y en a pas. Mentionner l'attraction, ici totalement virtuelle, entre les sexes n'a strictement rien d'une remarque sexiste. D'ailleurs, si l'invitation s'adressait à une des charmantes mappeuses (ai-je le droit d'écrire cet adjectif aux yeux de la police de la pensée?), la rencontre avec d'autres jolies femmes pourrait, virtuellement, transporter l'une d'entre elles. ;-) Christian Rogel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-newbies] Wiki documentation on GPS devices - please help answer some questions
Dudley Ibbett dudleyibb...@hotmail.com writes: I would also add that the section on PDOP is rather technical for a newbie. Perhaps this could be moved to a separate wiki page and the answer to the question changed to be more general. If your GPS has a display then this is more likely to be given as a distance. I must It's true that PDOP is perhaps too complicated, but there's good advice lurking: turn on your receiver and let it be still for several minutes with a good sky view before starting to record. In the woods, one can go for quite a long time and not acquire some satellites, and with only 4 up high get atrociius accuracy. By letting the ephemeris for all get loaded before hiking, the track accuracy is much better. For receivers without a satellite status page, the 'accuracy' number is useful. If one notices that you occasionally see a claim of '4 m', then when it says '21 m' you know you are in bad shape, and should wait. Basically, stay still with good sky view until that number gets to the lowest value you typically see. pgpJAnc9hxzB8.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-newbies] Wiki documentation on GPS devices - please help answer some questions
Hi Rob As a UK countryside mapper using a Blumax and Garmin 62s and JOSM I'd make the following comments: At this time my personal answer would be almost anywhere (path, tracks, roads etc. etc.). I also understand that the accuracy of the GPS trace will vary with time due to the position of the satellites (particularly when you're in a valley or on the side of a slope and I guess the same goes for when your in an urban environment.) so recording the same route repeatedly at different times would also be helpful. When editing having more gps traces certainly gives you greater confidence when drawing and/or adjusting elements. I suspect the answer to the use of phones, tablets etc is it depends on where/when you're mapping and how good the reception and therefore accuracy is. I always assumed the 62s would have better accuracy with an external aerial but experience shows that this isn't always the case and sometimes the Blumax, with its internal aerial is better. My suggestion would be just to encourage people to record and upload gps tracks rather than make any recommendations. I would also add that the section on PDOP is rather technical for a newbie. Perhaps this could be moved to a separate wiki page and the answer to the question changed to be more general. If your GPS has a display then this is more likely to be given as a distance. I must admit I never bother with this and generally leave determining the accuracy to when I use the traces for editing. However this only works if you already have map features of other gps traces. If the trace looks awful in the editor then I also wouldn't upload it. This work with JOSM but I don't know how this practice would fit with other editors. The section in http://wiki.openstreetmap.org/wiki/Accuracy is a much better answer to this question but even this could do with some diagrams to go with the text. I don't know what the rules are about moving or duplicating content on the wiki but as a newbie this is much more useful that PDOP. I get the impression that satellite numbers (http://en.wikipedia.org/wiki/File:ConstellationGPS.gif) and positioning in the sky is a bigger issue than multipath reflection but might be wrong. Apparently the latter is less of an issue when moving quickly in a car. Something to be added to the section on the in vehicles section? I use the BT747 (http://wiki.openstreetmap.org/wiki/BT747) application for talking to the Blumax and converting traces to GPX format. Hopefully others will comment as it is good to see these pages being updated and make more user friendly for newbies. Kind Regards Dudley Date: Sat, 19 Jan 2013 13:54:16 + From: rob.j.nicker...@gmail.com To: talk@openstreetmap.org; newb...@openstreetmap.org Subject: [OSM-newbies] Wiki documentation on GPS devices - please help answer some questions Hi All, I have been updating the wiki pages about recording, converting and uploading GPS tracks. My aim is to have these 3 pages (record, convert, upload) acting as a nice guide. == Progress so far == 1. I updated the Upload page [1] to bring it up to date with the fact that GPS data is just one part of the picture. The original page was from a time when aerial imagery and other data sources were not available. I also moved FAQ questions to this page. 2. I rewrote the Making GPX Tracks tool to include the fantastic online conversion tool at GPSVisualizer.com (no need to confuse people with GPSBabel software). A simple how to for conversion is now prominent at the top of the page. Technical details at the bottom. == Current project - Where I need your help == 3. I have started to update the page on recording GPS tracks [3]. This is where I need your help. There are some obvious questions that should be addressed on this page: * Can I use a iPhone / Android phone? What is the accuracy like? Which Apps are best? * Where should I record tacks? If the answer is anywhere, then where would you recommend I focus my attention (e.g. rural roads)? Is this the same globally? What should the page say in regard to these questions? All thoughts welcome. == Future == Really the page titles should be updated to Recording GPS traces, Converting GPS traces and Uploading GPS traces. How do I move the pages without messing up the language stuff? Is it possible to mass move all translations at the same time? Regards, RobJN [1] http://wiki.openstreetmap.org/wiki/Upload [2] http://wiki.openstreetmap.org/wiki/Making_GPX_Tracks [3] http://wiki.openstreetmap.org/wiki/Recording_GPS_tracks ___ newbies mailing list newb...@openstreetmap.org http://lists.openstreetmap.org/listinfo/newbies ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Subreddit Has 666 subscribers
In case anyone here reads the popular online news aggregation site Reddit, there is a subreddit dedicated specifically to OpenStreetMap, and as of today, it now has over 666 followers. Why do I care about 666? It's not because of any mystical or religious significance, I just didn't notice when we'd past 500 and I'm too impatient to wait until we've past 1000 to post this. If anyone here is a redditor, please subscribe, or better yet, if there are OSM related stories you know about, post them! - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM Data Edit-a-thon, Saturday, January 26th
Hi OSMers, OpenStreetMaps US is organizing an editing event in the US Saturday, January 26th, from noon EDT to 6PM PDT (or later). We encourage all members of the OSM community to participate, and ask you to visit http://www.openstreetmap.us/ for more information about the event. Please contact me if you have questions and/or information about gatherings not currently listed. Best Regards, -- John Novak 585-OLD-TOPOS (585-653-8676) http://www.linkedin.com/in/johnanovak/ OSM ID:oldtopos OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] uMap Project: OSM everywhere
On 03.01.2013 22:51, Yohan Boniface wrote: sorry for the late feedback, I was offline for some days. This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). the name umap is not very well chosen: there is already a project called uMap which exists since long time! http://wiki.openstreetmap.org/wiki/User:Speedpilgrim So it would be nice if you would change the name of your project. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] uMap Project: OSM everywhere
Michael Kugelmann wrote: This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). the name umap is not very well chosen: there is already a project called uMap which exists since long time! http://wiki.openstreetmap.org/wiki/User:Speedpilgrim I don't see umap anywhere there at all. I do see µMap, as in: https://en.wikipedia.org/wiki/Mu_%28letter%29 Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] uMap Project: OSM everywhere
On 01/21/2013 11:03 PM, Michael Kugelmann wrote: On 03.01.2013 22:51, Yohan Boniface wrote: sorry for the late feedback, I was offline for some days. This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). the name umap is not very well chosen: there is already a project called uMap which exists since long time! http://wiki.openstreetmap.org/wiki/User:Speedpilgrim So it would be nice if you would change the name of your project. I'm open to suggestions :) Yohan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-newbies] Tracing and offset error
Thanks for the reply Michael, My concern was not so much about the imagery being out of date, as I only trace places that I am very familiar with albeit having visited a long time ago. I will be visiting a few places I have mapped soon and will be having my GPS switched on all the time. It generally has good accuracy +- 3m, so should be a good start to help correct any potential offset errors if any. Regards On 8 December 2012 10:16, Michael S mich...@elfu.de wrote: Since I am also interested in this discussion I'd like to crosspost my answer also to the talk mailing list: Hello Gerhardus, In the absence of immediate local presence, is tracing acceptable and not wasted effort. Personally I only do aerial image mapping to a limited extent because I fear that I will map wrong objects (e.g. nonexisting buildings, roads) because of outdated bing images. I feel much more comfortable to do bing mapping when I also do know the surrounding by own survey. However, I would follow a pragmatic approach: E.g. If there is no railway at all in the map, and you think that it is likely that the railway is still there I would go for remote mapping. Offset Problem: Maybe you could compare objects already being mapped on a large scale ( larger towns ) and only do large scale mapping like major roads, but no micro mapping like lake boundaries on a 50 m scale without having better offset information. Michael Am 01.12.2012 13:59, schrieb Gerhardus Geldenhuis: Hi I have mainly been doing tracing of Bing images in far flung corners of the world where I have been. However I have been reading about offset problems with Bing imagery and was wondering if this would all be wasted work? I have mainly been doing work in Zimbabwe and South Africa with work being classified as: - Tracing and classing buildings - Making lake outlines more accurate. Lake Kariba as an example is a bit rough and ready. This is mainly prep work so I can add marinas and other amenities. - Tracing railway lines and roads in northern Zimbabwe. I might revisit a number of the places I have edited and will then be able to get some GPS traces, building names etc that I could use to compare offset with. But in the meantime is there any other way to determine the offset of satellite imagery? So to summarize my questions: - In the absence of immediate local presence, is tracing acceptable and not wasted effort. - Is there a reliable way to determine offset in a specific location without GPS track data Regards -- Gerhardus Geldenhuis ___ newbies mailing listnewbies@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/newbies ___ newbies mailing list newb...@openstreetmap.org http://lists.openstreetmap.org/listinfo/newbies -- Gerhardus Geldenhuis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM import stats
Frederick and all, I found your SotM presentations on OSM imports regarding disks and stats.I just completed a full planet import via osm2pgsql. Are you interested in the stats from my import? I *think* there's a wiki page about import stats, should i put them there. Long story short: 3 HDD 5400 rpm, RAID 5, took 570030 seconds overall (6.6 days). This includes indexing. I had a question i've never seen address. I followed recommended tunings for PostgreSQL for the import. Do you recommend keeping these settings or adjusting them for normal usage? I will re-enabling fsync. Brian -- http://brian.derocher.org https://mappingdc.org http://about.me/brian.derocher ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM import stats
The wiki page you are looking for is: http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks It's worth mentioning on there the other settings that you had used. Shaun On 17 Dec 2012, at 15:19, Brian DeRocher br...@derocher.org wrote: Frederick and all, I found your SotM presentations on OSM imports regarding disks and stats. I just completed a full planet import via osm2pgsql. Are you interested in the stats from my import? I *think* there's a wiki page about import stats, should i put them there. Long story short: 3 HDD 5400 rpm, RAID 5, took 570030 seconds overall (6.6 days). This includes indexing. I had a question i've never seen address. I followed recommended tunings for PostgreSQL for the import. Do you recommend keeping these settings or adjusting them for normal usage? I will re-enabling fsync. Brian -- http://brian.derocher.org https://mappingdc.org http://about.me/brian.derocher ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM import stats
Am 17.12.2012 16:19, schrieb Brian DeRocher: Frederick and all, I found your SotM presentations on OSM imports regarding disks and stats.I just completed a full planet import via osm2pgsql. Are you interested in the stats from my import? I *think* there's a wiki page about import stats, should i put them there. Brian, the wiki page is here: http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks 6.6 days seems to be very long though. SImon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk