[OSM-talk] Osmose's News since March
Hi, The biggest step in this period is the coverage of new countries: - Full Africa support - Europe: a number of new small countries: Azores, Albania, Bosnia and Herzegovina, Bulgaria, Croatia, Cyprus, Estonia, Hungary, Isle of Man, Kosovo, Latvia, Liechtenstein, Lithuania, Macedonia, Malta, Montenegro, Moldova, Romania, Serbia and Slovenia. - Europe: a new analyser server in the Netherlands, country divided in regions. - Southeast Asia is a new server in Germany covering Thailand, Brunei, Burma, Cambodia, Laos, Malaysia, Singapore and Vietnam. - Add countries in Asia: Sri Lanka, Syria, Tajikistan, Turkmenistan. - Add Central American countries: Belize, Cuba. Countries that are not supported by new servers were supported on OpenStreetMap-France or Iceland ones. Now there is a Coverage Map on Osmose: http://osmose.openstreetmap.fr/map/#zoom=2&lat=0&lon=0&layer=Mapnik&overlays=FTFT Meanwhile, new translations came Portuguese, Polish, Japanese and Hungarian. On the back side engine, fewer bugs and more unit testing and improving mechanisms for testing. Also, added support for a variable number of objects involved in an error. For data integration proposal analysers, redesign the code format to go to something more descriptive and structured, so less code, more configuration and convention. Improved data integration proposal analysers to add a "dynamic" support. It means manage a large number of different tags for the same OpenData set (typical French sports fields that have 180 different combinations of tags for the same dataset). On the side of analysers them self, not so many news. This period was a time of maturation, improve the quality and "conquer the world". - 2060/6 Improved Analysis "number twice in the street" - 2060/10 addr: housenumber does not start with a number - 2060/11 Multiple names for the same reference FANTOIR (France only) - 2060/12 Tag "addr:city" not consistent with the city - 2060/13 the object does not match the type FANTOIR (France only) - 7090/3 Isolated barrier - 8160/1 Unintegrated Paris Autolib ' (Paris only) - 8170 Dynamic analyser for sports pitch integration (France only) - 8190 Unintegrated French military Police (France only) - 8040/71 Bus stop in Wallonia (Wallonia, Belgium only) - 1150 Big optimization on "intersection between surfaces", save computation time on large countries. - suppression of import of OpenStreetBugs On the web interface, adding export to RSS, GPX and remote "everything to JOSM." Finally, a bridge between Osmose and Maproulette was established. It allows send certain types of errors on the addictive interface of Maproulette. For now, a small number of test categories are sent. These are the categories that begin with "[world]" and "[France]." http://maproulette.org/ For the near future we have plan to support all America except the two biggest countries. On large countries (in data) we still need your help to find new servers for Osmose backend analyser. http://osmose.openstreetmap.fr Frédéric. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
Hi all The (long) discussion about importing Wikidata tags in OSM has prompted this idea into my mind: https://wiki.openstreetmap.org/wiki/OSMdata I have also describe here in the IdeaLab on meta-wiki: https://meta.wikimedia.org/wiki/Grants:IdeaLab/OSMdata:_a_Wikidata-like_editor_for_OpenStreetMap Here's a quick summary: == What == * using a MediaWiki + Wikibase - let's call it OSMdata[*] - install to host an item about every single object in OSM (following this schema Nxxx for nodes, Wxxx for ways, Rxxx for relations). * claims in a OSMdata page about an item map exactly to key, values pairs for the same object in OSM. * OSMdata is synchronized and kept up-to-date with the OSM database (read) * users can login in OSMdata with their OSM account and contribute, adding new claims this are saved back automatically in the OSM database (write) == Rationale == * it seems awesome (!) * the OSM community gains a new editor for OpenStreetMap, an editor which use a well known interface and which can get all the benefits of MediaWiki+Wikibase software development * Wikibase is tested at 60x its current scale * Wikibase is used in another big project Let me stress again that I see OSMdata as being an editor, not a repository for OSM, in fact I image in it to be a specialized editor to be used for editing tags. In my view the idea is to provide a well known interface to edit OSM (both manually and automatically with bots, using the same bot frameworks already available for editing Wikidata). I have described this idea in the talk-it malling list (in Italian) and a (at least conceptual) similarity has been pointed out towards the textual editor Level0[2]. I would like to know your opinion, and I would also like to set up some prototype with a small subset of the data. I tried to set up this myself but, unfortunately, I am blocked on the first obstacle, i.e.: how can I tell Wikibase to let me create items with names Nxxx, Wxxx and Rxxx instead of Qxxx? I do not know enough PHP (nor MediaWiki or Wikibase) to do this myself. Any help in this direction would be much appreciated. Ciao, Cristian [*] any reference to Wikidata is purely intentional [1] https://lists.openstreetmap.org/pipermail/talk-it/2014-September/044540.html ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
I have been proposing a very similar idea, where OSMdata would be used for data that is not suitable for the main OSM database, but is not notable enough for Wikidata. For example: link objects to other databases, adding stuff like restaurant reviews, creating categories which are not suitable for relations and so on. But the way I thought it would be used is to add a new item to OSMdata, and then link it to OSM with its OSMdata ID, "osmdata=Oxxx". That way the link to an object would be stable, so if you convert a node to a way, you just copy the osmdata id. Your proposal to just shift the whole database to OSMdata is interesting. I think a dynamic link could also be possible. OSMdata could just query the main database when you ask it for N40983. It doesn't have to have a copy of the whole database. Janko Mihelić 2014-09-12 11:41 GMT+02:00 Cristian Consonni : > Hi all > > The (long) discussion about importing Wikidata tags in OSM has > prompted this idea into my mind: > https://wiki.openstreetmap.org/wiki/OSMdata > > I have also describe here in the IdeaLab on meta-wiki: > > https://meta.wikimedia.org/wiki/Grants:IdeaLab/OSMdata:_a_Wikidata-like_editor_for_OpenStreetMap > > Here's a quick summary: > > == What == > * using a MediaWiki + Wikibase - let's call it OSMdata[*] - install to > host an item about every single object in OSM (following this schema > Nxxx for nodes, Wxxx for ways, Rxxx for relations). > * claims in a OSMdata page about an item map exactly to key, values > pairs for the same object in OSM. > * OSMdata is synchronized and kept up-to-date with the OSM database (read) > * users can login in OSMdata with their OSM account and contribute, > adding new claims this are saved back automatically in the OSM > database (write) > > == Rationale == > * it seems awesome (!) > * the OSM community gains a new editor for OpenStreetMap, an editor which > use a well known interface and which can get all the benefits of > MediaWiki+Wikibase software development > * Wikibase is tested at 60x its current scale > * Wikibase is used in another big project > > Let me stress again that I see OSMdata as being an editor, not a > repository for OSM, in fact I image in it to be a specialized editor > to be used for editing tags. > In my view the idea is to provide a well known interface to edit OSM > (both manually and automatically with bots, using the same bot > frameworks already available for editing Wikidata). > > I have described this idea in the talk-it malling list (in Italian) > and a (at least conceptual) similarity has been pointed out towards > the textual editor Level0[2]. > > I would like to know your opinion, and I would also like to set up > some prototype with a small subset of the data. I tried to set up this > myself but, unfortunately, I am blocked on the first obstacle, i.e.: > how can I tell Wikibase to let me create items with names Nxxx, Wxxx > and Rxxx instead of Qxxx? I do not know enough PHP (nor MediaWiki or > Wikibase) to do this myself. Any help in this direction would be much > appreciated. > > Ciao, > > Cristian > > [*] any reference to Wikidata is purely intentional > [1] > https://lists.openstreetmap.org/pipermail/talk-it/2014-September/044540.html > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
2014-09-12 13:58 GMT+02:00 Janko Mihelić : > But the way I thought it would be used is to add a new item to OSMdata, > and then link it to OSM with its OSMdata ID, "osmdata=Oxxx". That way the > link to an object would be stable, so if you convert a node to a way, you > just copy the osmdata id. @Janko I don't understand how this link would be stable. The reason for osm objects to get new IDs is typically someone splitting the object, transforming a point into an area or similar. Now how would having links to another external db help here? As a mapper you would either not care (i.e. the data will deteriorate like any other data that is not cared for) or you'd have to go looking in externalDB what the link is about, and whether you'll keep it on the original node (for instance) or move it over to the area (for instance), or in the case of a split way, whether you'd want the link on all pieces or only on some. External DBs that have to be linked from within osm are not an improvement at all, rather they'd complicate the life of osm contributors even more because they'd have to check these links in order to make good edits. If you want to set up a DB about restaurant reviews, please do this without the need to link from osm, e.g. with name comparison and spatial proximity, by looking at the operator, etc. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
On 12.09.2014 11:41, Cristian Consonni wrote: > The (long) discussion about importing Wikidata tags in OSM has > prompted this idea into my mind: > https://wiki.openstreetmap.org/wiki/OSMdata I don't quite understand the benefits compared to presets yet. Adding Wikibase functionality to the OSM *Wiki* would be awesome in my opinion. Using it to edit OSM data, however, does not sound that intuitively appealing when more specialized tools are available. But perhaps you can elaborate? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
2014-09-12 14:12 GMT+02:00 Martin Koppenhoefer : > > If you want to set up a DB about restaurant reviews, please do this > without the need to link from osm, e.g. with name comparison and spatial > proximity, by looking at the operator, etc. > You're right, "Overpass Permanent ID"[1] property in OSMdata is probably better than writing an ID on the object in most cases. But maybe sometimes directly linking by ID would be better if a query is difficult to point at some object. Janko [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
On Fri, Sep 12, 2014 at 2:20 PM, Tobias Knerr wrote: > Using it to edit OSM data, however, does not sound that intuitively > appealing when more specialized tools are available. But perhaps you can > elaborate? It is worth noting that Wikibase doesn't need to be the edition interface. You can have it running on the background and use a custom GUI to display/edit some preset fields which use the entity suggester in whatever language the user has chosen. Examples: https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:WE-Framework The benefits are that you could use it as an authority control gateway, structured relations, better interoperability, and reuse of the tools/development that is being done for wikibase. I don't know OSM well enough to appraise if these benefits outweigh the costs, but perhaps it is worth taking a closer look. Cheers, Micru ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
Hi, 2014-09-12 14:37 GMT+02:00 David Cuenca : > On Fri, Sep 12, 2014 at 2:20 PM, Tobias Knerr wrote: >> >> Using it to edit OSM data, however, does not sound that intuitively >> appealing when more specialized tools are available. But perhaps you can >> elaborate? > > It is worth noting that Wikibase doesn't need to be the edition interface. > You can have it running on the background and use a custom GUI to > display/edit some preset fields which use the entity suggester in whatever > language the user has chosen. Examples: > https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:WE-Framework > > The benefits are that you could use it as an authority control gateway, > structured relations, better interoperability, and reuse of the > tools/development that is being done for wikibase. > I don't know OSM well enough to appraise if these benefits outweigh the > costs, but perhaps it is worth taking a closer look. Since Micru has already pointed out some of the benefits, I'd to subscribe to his list adding the fact that the reuse of Wikibase can allow to, say, export all the data in RDF format, once this functionality is developed for Wikidata. On the other hand, put very simply, you could see this project as a (yet) another editor for OpenStreetMap with the plus that you are reusing a well-known software that already comes with a number of extensions and tools and it's actively developed by a vast community. After looking at Level0, one way that I imagine this project is some sort of "Level0 on steroids". Cristian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
Am 12.09.2014 11:41, schrieb Cristian Consonni: > > Let me stress again that I see OSMdata as being an editor, not a > repository for OSM, in fact I image in it to be a specialized editor > to be used for editing tags. While the idea has a certain appeal, as in "lets try something really crazy with wikidata", and it would be a fun project just for that, I'm not quite sure about the the "serious" part of the proposal. Setting up a tag-only editor for OSM is not a problem, it just doesn't seem to add any significant value. And in this case would likely require a significant effort to get any changes out of the OSMdata DB as edits back in to OSM proper. I -do- believe that there is space for a handful of wizards (or "guided editing" if you want) along the lines of "add my business", "add my address" etc. However writing one of these that really works is not trivial and needs logic that understands geometry, the different ways the same object can be represented in OSM and so on, and hasn't been done to date. . > In my view the idea is to provide a well known interface to edit OSM > (both manually and automatically with bots, using the same bot > frameworks already available for editing Wikidata). .. It is already far to easy to modify OSM-tags per bot, I'm not sure why we would want to make it even "easier" (I'm not sure if that would actually be the case any way). Simon signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
Maybe OSMdata could be used to make auto-generated nice pages for businesses and other POIs. A little map, telephone number, opening hours, webpage link, a picture if it's connected to wikipedia, or if it has an image=* tag, and so on. Then when search engines indexes it, people will get that as a page for their local shops. And you can edit it on the spot. Some people at Wikidata suggested a redesign along those lines [1]. [1] http://www.wikidata.org/wiki/Wikidata:UI_redesign_input ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdata: a Wikidata-like editor for OpenStreetMap
Il 12/Set/2014 18:31 "Janko Mihelić" ha scritto: > > Maybe OSMdata could be used to make auto-generated nice pages for businesses and other POIs. A little map, telephone number, opening hours, webpage link, a picture if it's connected to wikipedia, or if it has an image=* tag, and so on. Then when search engines indexes it, people will get that as a page for their local shops. And you can edit it on the spot. The idea of specialized rendering of items based on the object type is explored - in Wikidata - by the Reasonator, see: http://tools.wmflabs.org/reasonator/ Cristian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visually detect missing roads
Am 09.09.2014 09:22, schrieb Mateusz Konieczny: It would be useful to allow switching between diff, OSM only and google only. Currently in my area results are too confusing to be useful. +1, same to me... Cheers, Michael. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] keys with multiple values
On 11/09/2014, Andrew Hain wrote: > > The TIGER import used name_n istead of alt_name_n. > > Have any data consumers got a preference for one or the other? To me there's very little semantic value in distinguishing between name_2 and alt_name. Even old_name and loc_name arguably don't bring much to the table (I do see the nuance, but it doesnt seem to be worth the complication). We've got the same problem with the ref tag and many others. We've invented loads of conflicting schemes because there's no obviously correct solution for this common problem. To me it's a failure in the osm data model, like the lack of a dedicated "area" object type. It should be possible to assign an ordered list of values to a key, without resorting to a confusing collection of hacks. Maybe an update to the data model would be so disruptive that it wouldn't be worth it. Maybe we could decide instead on a key separator that only and always indicates an alternate value (neither "_" nor ":" fit the bill). But it'll face the usual adoption uphill battle (xkcd 927), and efficiency/ambiguity issues (like the current use of relations and implicit area=yes/no tags to identify areas). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] keys with multiple values
On 9/12/2014 3:24 PM, moltonel 3x Combo wrote: To me there's very little semantic value in distinguishing between name_2 and alt_name. Even old_name and loc_name arguably don't bring much to the table (I do see the nuance, but it doesnt seem to be worth the complication). We've got the same problem with the ref tag and many others. I believe with TIGER these were not alternate names, but different names, none of which were clearly main or alternates in the data. It's one of those things that makes raw TIGER data a pain to work with. That situation is distinct from when you have a primary name and multiple alternate names, although in practice many of the TIGER cases had a primary name, or one of the alternate names wasn't really a name. TIGER is also not where to look to for good tagging practices. For various reasons, there were numerous problems with the tagging. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
