Re: [OSM-talk] mapilio? (street-level imagery)
Le 01/06/2023 à 09:09, Simon Poole a écrit : Am 31.05.2023 um 22:08 schrieb Christian Quest: ... OSM editors integration. That was one of the reasons why I was asking, as I have already done some work on a STAC layer based on the GeoVisio API. In that case you've already done Panoramax integration or a big part of it :) I pushed Adrien to implement STAC support some months ago to stay in an existing standard. For example, we're currently looking how to add access to statistics in our API, and STAC has statistics extension... so we will at least support it as far as possible ! First million pictures should be here is a very short term (combining IGN and OSMFR instances). -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapilio? (street-level imagery)
Le 31/05/2023 à 09:25, Simon Poole a écrit : Christian, does this relate in some fashion to Geovisio? And a, I suppose, obvious observation: key for adoption in OSM would be an easy to access API for editing apps. Does that exist/are there plans for one? Simon Hello Simon, Geovisio is the reference code base for the Panoramax project (think of Geovisio as one of OSM code stacks, and Panoramax as the OSM project as a whole). What we try to do is to set open standards to allow different implementation of the common protocols to provide interoperability betweens instances. I would love to see local instances setup in the future all federated. We decided to use an existing standard called STAC (Statio Temporal Assets Catalog) to avoid creating one more new standard. Geovisio originally has its own API, but now moved to STAC which is REST/JSON. Anybody implementing a STAC API based viewer should be compatible. This API allows to search for pictures based on time and location (at least). Pictures are organized as collections. The current work is focused on uploading pictures, bluring them to respect privacy, access them thru the STAC API used by the Geovisio viewer. The additional pieces that would be great to have next are: mobile app to capture pictures, usefull object detection for OSM reuse (I'm working on road signs), OSM editors integration. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapilio? (street-level imagery)
Le 24/05/2023 à 14:31, Greg Troxel a écrit : I just got spam from mapilio, implying that I was a "Mapilio contributor". This was, to my memory, the first I had heard of them. I have avoided most street-level imagery schemes as not being structurally similar to OSM (open source tooling, community project and licensing scheme). I'm not answering directly to your post, but I think you may like my answer ;) I'm currently working on the Panoramax project, co-originated by OpenStreetMap France and IGN (Institut Géographique National). In the very near future, we should have a street-level imagery offer that matches: - open source tooling - community project - (real) open licensing scheme as well as... - decrentralized / federated solution... to avoid having one more time a single point of failure with an actor hosting all the pictures ! We have not communicated much so far except in France on https://panoramax.fr/ as we're still working on the MVP. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] humanitarian rendering in a degraded state
Humanitarian tiles are back online after a DB reimport. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Face and license blurring (GDPR territories)
Le 06/10/2020 à 22:41, Nick Whitelegg a écrit : Hi, Apologies if this is only tangentially OSM related, but I thought I'd ask here to try and get some expert advice. As you may know, Mapillary has been bought by Facebook and there has been interest in developing, or at least starting to develop/actively researching the possibility of, some sort of open source alternative. I have been developing OpenTrailView (opentrailview.org), however I now have a collaborator to work on exploring an open source panos platform. The main question I have relates to the very necessary privacy steps that must be taken, in particular face and license plate blurring. I have experimented with various libraries using various datasets and models, and have found that the understand.ai Anonymizer (https://github.com/understand-ai/anonymizer), which advertises itself as something specifically aimed at implementing the privacy protections needed to comply with the GDPR, seems to be working the best. It detects faces and license plates in clear view on panoramas, which can then be blurred. My question, then, is what to do about people, or cars, which are further away from the camera? In these cases, the algorithm does not necessarily detect the face or license plate, but on the other hand in general the faces and license plates are not clearly visible, or identifiable, in any case. So in summary, the tool blurs clearly visible faces or license plates, but in general does not blur those which are not clearly visible. Apologies once again that this is only tangentially related to OSM (OpenTrailView uses OSM to connect panos together, so not completely unrelated) but it is very much an open geodata issue, so I thought I'd ask to get feedback. I am in the UK and the server is in Germany (Hetzner), so GDPR would apply. Thanks, Nick We have tested blurring using image segmentation which allows to blur full parts of pictures like people and cars, not only faces and license plates. Here is the result: https://takeitout.cquest.org/photo/cquest/blurred/ The code used is on github: https://github.com/tyndare/blur-persons/ We did some tests using TPU to speedup the process. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] {Disarmed} Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
Le 01/08/2020 à 02:27, Guillaume Rischard a écrit : Hi all, The OSMF Board wants to facilitate and support improving infrastructure. During the Microgrants process, there were proposals that didn’t make it, but would together be a good pilot for a “OSM infrastructure” process, to learn how supporting osm infrastructure projects works well. The OSMF Board wants to fund a limited number of projects proposed by trusted long-term volunteers whose work we know and enjoy. We have selected the osm2pgsql and Potlatch microgrant proposals, and have a new proposal from Nominatim. In the long term, we want to re-activate the Engineering Working Group (EWG) by making it a place for decision making, project guidance and budget management for such projects. The Board would like your feedback on these three specific infrastructure projects: Very good news ! Infrastructure is not only hardware and network, it's also code and humans to make all this run as smoothly as possible. If enough funds are available for all project, they should all be funded. For a long term view, helping new devs to get familiar with old code is a key to maintain legacy code when it still represent a large dependance in the infrastructure. By infrastructure I see the OSMF one, but also all the OSM ecosystem. osm2pgsql is a good example of a key tool used by a lot of people (not only OSMF). We've seen recently with a single changeset causing failed updates how dependant a lot of people can be from that "old code". I'm also thinking the same about mod_tile/renderd, where maintenance seems minimal. nominatim seems less broadly used, but it still is an important tool on OSMF web site. potlatch... I don't really put it in the infrastructure, but if funds are available why not give it a few more years life even if a tiny portion of changesets are made with it. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers
Le 08/03/2020 à 16:00, Mario Frasca a écrit : well, it does look slightly invasive … That's the goal... slightly invasive... and not time consuming for the tile server and myself. Please, don't forget who's wrong here. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers
Here are a few examples: http://www.ardennes-neige.be/ http://autogas-network.co.uk/ http://mapa.guadalajara.gob.mx/basura http://vivenda.hercesa.ro/ https://www.visitarnhem.com/routes/wandelroutes The reminder tiles is in available english and french: https://tilecache.openstreetmap.fr/attribution-en.png https://tilecache.openstreetmap.fr/attribution-fr.png I mix both at different locations on the maps. Automatic attribution checking for one day of log files now takes around 20 minutes. I'll clean the nginx config file and share it. Le 08/03/2020 à 15:05, Mario Frasca a écrit : On 08/03/2020 05:04, Yves wrote: Ps: would you share your nginx partial redirect, I may consider it for Opensnowmap tiles policy? On 08/03/2020 06:12, Simon Poole wrote: anything that deliberately defaces a web site On 08/03/2020 07:13, Christian Quest wrote: just 1 tile out of 25 very interesting experiment, and very amusing results. bravo. I would say that 1 in 25 is low enough as not to be considered "defacing" a web site. what text have you used, concretely, which had the impact you describe? in my opinion the shortest, the better, and I guess you did NOT use »It looks like this site forgot to put the required attribution in this map corner, so we added it for them. Thx for using OpenStreetMap !«, did you? it was in French, wasn't it? my best guess would be nothing else than the attribution text, and some help to solve their situation, or to get in contact with you. I absolutely share the point of view "contact emails lead to no contact", and the "whatever works" policy. this seem to work, so again, chapeau! indeed, it would be interesting to see your nginx partial redirect. MF ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers
Le 08/03/2020 à 12:12, Simon Poole a écrit : Just for the record: Enforcing attribution for services that you are providing directly (aka tiles in some form) only has a small overlap with the goals of the attribution guideline, and the avenues open to you depend on your ToUs / contracts with your users and the legal situation in the countries you are providing the service in. It simply demonstrates that as a tile provider, you can technically detect lack of attribution and enforce it. I would be very very wary of doing anything that deliberately defaces a web site without consulting with a local (to the country the web site is in) lawyer, particularly if the message implies wrong doing. The safe, I admit also the less fun, option, is to simply block access after giving any required notice. Giving notice is ususally difficult. Contact emails are not read or people reading them do not know how to handle it, who to forward it to, etc... These attribution reminder tiles are a (highly) visible notice and just 1 tile out of 25... 96% of the basemap is there (now partially attributed). Maybe changing the wording to "It looks like this site forgot to put the required attribution in this map corner, so we added it for them. Thx for using OpenStreetMap !" ? ;) -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers
Here is a hort report on this experiment... I started a week ago by searching OSM France tile server logs for referer and checked manually if the map on the refering page was correctly attributed. This allowed me to create a short list of 20 entries of sites using the french styled tiles and the humanitarian tiles (yes, it is made by OSM France). I then modified our nginx based proxy_cache configuration, to redirect some tiles to an "attribution tile" only for the domain in the list. For two of them, I tweeted about it... the most visible one is the moroco yellow page service, generating a little less than a million daily tile requests on our servers. https://twitter.com/cq94/status/1234516075695525888 In less than 24 hours, the attribution appeared and I removed them from the list. https://twitter.com/cq94/status/1234779931537739776 Then I included an email address in the attribution reminder tile... and got emails back within a few hours. Some were asking how to do the attribution, others telling me the attribution was now ok and asking how to remove the reminder tiles. In my answers, I also remind that our tile service made by volunteers on donated hardware is not unlimited and inviting them to have a look at switch2osm to setup their own tile server or use a commercial provider. Up to now, nobody complained :) Yesterday, I've started automating attribution checking using selenium. For each referer, a python script loads the page, searches for tiles, then looks for attribution text or link. The result is stored in a postgresql database which allows to group referers by url, hostname and ip. The attribution percentage I currently see is around 70-80% which is not that bad. My next major step is to use the same technique to remind about tile usage policy... To do something similar on osm.org, a first step is to extract referers from the cache logs, then use the automated attribution check to evaluate the situation. Le 08/03/2020 à 01:52, Nuno Caldeira a écrit : That would be a good option for those that use third party providers of OSM. But to be honest, from my experience I highly doubt that even corporate members of OSMF, like Mapbox would do it, when their client Facebook (also corporate member of OSMF) after one year and half, still has maps with lack of attribution or attributed to HERE, when it's clearly OSM. On Sun, 8 Mar 2020, 00:46 Phil Wyatt, <mailto:p...@wyatt-family.com>> wrote: I am sure others may have seen this 'blacklist' implementation for showing a reminder about attribution. https://twitter.com/cq94/status/1234528717604577282 Worthy of consideration for openstreetmap.org <http://openstreetmap.org>? Cheers - Phil -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Planet torrents...
After a few weeks experimenting planet dump sharing thru bittorrent, here is a short report. I've fully automated the process on my side: - new planet pbf availability detection - planet pbf download - torrent generation - torrent publishing and initial seeding This week was the first one I had nothing to do (or fix) :) In a couple of hours, we have around 4 to 5 seeds, 24 hours laters, that's around 10. Once seeded, it takes 30 to 40 minutes to download the planet dump (if you have fast internet connection like optic fiber). My own seeds (3) have a download/upload ratio around 3 (I've send 3 times the planet file on each seed). Do not hesitate to share your own findings if you have tested the planet torrents ! -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Attribution guideline update
Le 19/02/2020 à 09:59, Simon Poole a écrit : The LWG has now integrated feedback from the initial airing in August last year, from a total of three sessions at SOTM-US and SOTM in Heidelberg, feedback from the OSMF board and from the wider OSM community. Barring any major late developing issues, we intend to forward this to the OSMF board for formal approval at the next LWG meeting on the 12th of March. If you have any comments please feel free to add them to the wikis talk page. The updated document can be found here https://wiki.openstreetmap.org/wiki/Draft_Attribution_Guideline Simon PS: please disregard the numbering in the document, that will not be present on the OSMF wiki. Thank you Simon ! Like many others, I hardly agree on 2 things: - the 10.000m2 limit, this is completely artificial - the mobile rule allowing an interaction to access the attribution The minimal "(C) OpenStreetMap" attribution requires very few pixels, less than 150. When this space is available, direct attribution should be there, whatever the size of the screen or type of device. When multiple attributions are required (from OpenStreetMap and others) and space is limited, a single "Copyright" with link or interaction could replace it. This eliminates the battle for screen space between Mapbox logo vs OpenStreetMap (because we're indirectly talking of that) and moves both at the same attribution level. Setting such a fixed limit could also solve the thumbnail problem... a 150px wide image can't deliver so much map data... -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Testing torrents for the planet dump
Le 09/02/2020 à 19:21, Yuri Astrakhan a écrit : Christian, I would like to add torrent support to the download-osm tool [1]. While I could try to scrape https://osm.cquest.org/torrents/ , I would obviously rather use the structured xml file (or if you could provide a JSON file, even better). If you have a model for such a json, I can add it. Proposed logic: * get the catalog file (xml/json) * download the latest torrent * (TBD) possibly use some magical aria2c options to stop the download if it is not progressing and fallback to regular http, or possibly pick a slightly older torrent (?). Suggestions are welcome -- see full list of aria2c options [2] [1] https://github.com/openmaptiles/openmaptiles-tools#multi-streamed-osm-data-downloader [2] https://aria2.github.io/manual/en/html/aria2c.html I've not tested aria2c, but I tested lftp which supports bittorrent, example: lftp -c torrent https://osm.cquest.org/torrents/planet-latest.osm.pbf.torrent After the download is done, it switches to a background process to share the file up to a ratio of 2:1. Web seeds can be seen as fallback. I don't know if lftp (or aria2c) supports web seeds, the lftp documentation I found about the torrent support is minimal. aria2c support metalink files, which could be something to also look at: https://en.wikipedia.org/wiki/Metalink -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Testing torrents for the planet dump
Le 09/02/2020 à 18:26, Maarten Deen a écrit : On 2020-02-09 16:17, Christian Quest wrote: A couple of weeks ago, I've (re) started sharing planet dump files using Bittorrent to test an alternative way to distribute our planet dumps to reduce the bandwidth load on the OSMF servers. Here is a short summary after 2 weeks tests... The torrents are generated a few hours after the planet dump availability on planet.openstreetmap.org server (time needed to download the original file to generate the torrent). A question about updates of the torrent. The planet changes weekly. Suppose I download the plannet using the torrent and then also seed it, what happens when the next planet comes available? Do I need to use a different torrent to download it again or will the one I have be updated? Each planet file has its own torrent. A new planet file means using a new torrent to download it. To simplify downloading the lastest planet, you'll find a planet-latest.pbf.torrent similar to the planet-latest.pbf (it's a symlink to the last planet available). If you want to automate downloading new planet thru torrents, for example to seed them, there's a rss.xml file you can use. Many bittorrent clients support RSS to automate downloads. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Testing torrents for the planet dump
A couple of weeks ago, I've (re) started sharing planet dump files using Bittorrent to test an alternative way to distribute our planet dumps to reduce the bandwidth load on the OSMF servers. Here is a short summary after 2 weeks tests... The torrents are generated a few hours after the planet dump availability on planet.openstreetmap.org server (time needed to download the original file to generate the torrent). I'm seeding it from a couple of servers which allows to spread the dump file faster. Seeding is also done thru the original https link and main mirrors (this is the "web seed" feature supported by some bittorrent clients). After the initial seed, downloading the planet file can be as short as 30/40mn if you have a good downlink. After 3 days, there's currently 15 seeds, allowing event faster or more balanced downloads (just did one in only 15mn). If you have downloaded the planet dump using the torrent or plan to do so or want to test it, please share your results on the wiki discussion: https://wiki.openstreetmap.org/wiki/Talk:Planet.osm#Torrent The torrents are located at https://osm.cquest.org/torrents/ -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addressing SIG
We've been "addressing the address topic" for more than 5 years in France with our BANO project. Here is an overlay I created back then to show existing and missing address data in OSM compared to available OSM compatible sources. http://osm13.openstreetmap.fr/~cquest/leaflet/bano.html#16/48.7908/2.6542 Green: the address is in OSM (and the named road too) Blue: address is missing but the road name exist in OSM Red: address missing and we found no road with that name nearby If you want to make missing data obvious, you should no dimm the shapes, but make them highly visible. The goal with the above rendering became "dégommer du rouge" (get rid of red). Le mar. 5 nov. 2019 à 19:43, Steve Coast a écrit : > Hello > > > > Maps have three basic components: Display (does it look nice?), Routing > (Can I get from a to b?) and Geocoding (Where is this address?). > > > > OSM is extremely good at the first one, and pretty good at the second one. > But it’s pretty deficient in the third area: address data. > > > > The question is, how can we fix this? Addresses are a big, big problem in > terms of how much data we need to go collect. There are a few ways forward > with outside commercial or government data, but they tend to be difficult > because the data is patchy or licensed in ways that aren’t very compatible > with OSM. > > > > It seems like it would be a good idea to think about this from the bottom > up in a community way, and this doesn’t really exist in OSM right now. It > seems like we need better feedback loops to: > > > >1. Community can see where the address data is (and isn’t), because >it’s not very obvious today when using osm.org >2. Make the tools to add address data better so that it’s easier to >fix. > > > > To that end, here’s a tile server that highlights address data: > > > > > http://ec2-52-50-19-165.eu-west-1.compute.amazonaws.com/#10/39.7561/-104.9574 > > > > It shows roads with address data normally and kind-of hides other roads, > to make it obvious that “something is wrong with this map”. We could have a > tag (maybe it exists already) that says “this road doesn’t have addresses” > and/or a tag that says “this road is complete”. (right now it’s just got > Colorado and Utah in it). > > > > When OSM started, the map looked very broken and incomplete because there > was missing data all over the place. This created a large incentive to go > fix the map. The idea with this tileserver is to do the same thing and make > the map look broken to create a large incentive to fix it. If we, one day, > switched the main osm.org site to using this rendering then it would > create an urgent need to find all the addresses in the places where they > exist. It could also be done on a temporary basis for a few weeks, or on a > per-country basis or some other slow introduction to see if it worked. It’s > just an idea. > > > > On the tools side, there’s much that can be done to make collecting and > entering addresses easier. I’ve been collecting UI/UX changes to tools > (e.g. iD or Go Map!) that would make addresses better: > > > > https://wiki.openstreetmap.org/wiki/Address_SIG > > > > It also seems worthwhile to create a group of people interested in > addressing in OSM (an address special interest group or working group) to > push these ideas forward so that we can “finish” OSM by getting all the > addresses done. > > > > What do you think? > > > > Best > > > > Steve > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geocoding guideline
Very good outcome ! I've made a quick french translation: https://annuel2.framapad.org/p/guidelines-geocodage-osm Edits are welcome, as it is 95% automatic translation from https://www.deepl.com/translator (very good new translator)... plus my own 5% quick edits ;) 2017-08-29 11:10 GMT+02:00 Simon Poole : > > I'm happy to announce that the geocoding guideline was endorsed by the > OSMF board at its last meeting and is now published on the OSMF website > https://wiki.osmfoundation.org/wiki/Licence/Community_ > Guidelines/Geocoding_-_Guideline > This hopefully addresses and clarifies a long time, sometimes hotly, > debated issue and will make it easier to use OSM data in more applications. > > Thanks to all that worked on the text and provided feedback negative and > positive. > > Simon > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap carto "FR" v2017 online...
Le 02/01/2017 à 11:25, Christoph Hormann a écrit :
On Monday 02 January 2017, Christian Quest wrote:
I'm pleased to announce a new version for the "french style" tiles...
running on a brand new server donated by OVH.com
Very nice.
Thanks
Main new things compared to the international style:
- tidal=* rendering
I am somewhat confused about the tagging scheme you render here - is
that documented somewhere? Your water areas query:
(SELECT ST_Snaptogrid(way,!pixel_width!/4) as way,
\"natural\",waterway,landuse,amenity,
coalesce(tags->'name:fr',tags->'int_name',name) as name,
tags->'basin' as basin, water, surface
FROM planet_osm_polygon
WHERE (
waterway in ('dock','mill_pond','riverbank','canal') or
landuse in ('reservoir','water','basin','salt_pond') or
\"natural\" in ('lake','water','land','glacier','mud','bayx') or
amenity='fountain' or water='tidal')
and building is null and way_area > !pixel_width!*!pixel_height!*10
and way && !bbox! ORDER BY z_order,way_area desc) as water_areas
indicates you render any water area as well as any area tagged
water=tidal no matter what the primary tag is that has surface=rocky
with the rock pattern overlay. IMO this is not such a good idea
because it does not really encourage correct tagging - mappers can use
invalid primary tags (like natural=foo + water=tidal + surface=rocky)
or use nonsense combinations (like natural=mud + surface=rocky) without
the map indicating the mistake. Also the most common tag for
indicating tidal features is tidal=yes and not water=tidal.
You do not seem to render natural=shoal and wetland=tidalflat which are
the dominant ways of mapping tidal areas at the moment (though
admittingly wetland=tidalflat does not really make much sense for rocky
tidal areas which are usually not flat).
I've based my queries and css on the wiki.
tidal=yes + surface=* is documented
natural=shoal is not... in
https://wiki.openstreetmap.org/wiki/Key:natural so I could not find
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dshoal (used only a few
hunderd times BTW).
I've also added rendering for wetland=* in another layer
I'm sure I can improve all this and separate/merge these overlays in a
more logic way ;)
--
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap carto "FR" v2017 online...
I'm pleased to announce a new version for the "french style" tiles... running on a brand new server donated by OVH.com A summary of major changes is available (in french) : https://cquest.hackpad.com/Rendu-OpenStreetMap-FR-v2017-PYR3VV1ZrSe Main new things compared to the international style: - tidal=* rendering - leaf_type=* rendering - experiment with ST_Clusterwithin to cluster bus stops Happy new (mapping) year ! -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Building Detection using Machine Learning
One example: OpenSolarMap... We first start by crowdsourcing building roof orientations using a very simple webapp (no need to register, open to anybody). When enough contribution match they are considered OK (at least 3 more than all other contributions). Then, these contributions were used to train a neural network. Then the nueral network was used to classify other roofs... and the result has been put back as robot contribution to the crowdsourcing webapp counting for 1 or 2 contributions depending on the level of confidence (raw data is also available for download). In all cases, there is always at least one human contribution, before putting anything back to OSM. It is also interesting to compare when human and robot do not agree ;) Links... http://opensolarmap.org/ https://github.com/opensolarmap Next step is to use the same technique on other kind of challenges, like: - landuse boundaries (to speedup/simplify Corine Land cover import improvements) - check road alignment with aerial imagery on "old" OSM traced contributions etc... The potential of deep learning mixed with human contributions can give very good things if done properly. 2016-12-22 17:48 GMT+01:00 Mikel Maron : > > Frederik, all > > > an editor plugin were to help the mapper trace buildings that the > mapper identifies or at least individually verifies, that would probably > be ok > > This feels like the consensus across the board -- machine learning has > potential to be useful when integrated into a human editor workflow. Maybe > we can work on guidelines that encapsulates this. With something written > up, we'll be able to stop "spinning wheels" on whether this is useful or > not, and focus on experimenting and implementing promising approaches. > > -Mikel > > * Mikel Maron * +14152835207 @mikel s:mikelmaron > > > On Wednesday, December 21, 2016 7:59 PM, Frederik Ramm < > frede...@remote.org> wrote: > > > > Hi, > > On 12/22/2016 01:10 AM, john whelan wrote: > > Do we have any guidelines in the wiki etc? > > Nothing specific, no. > > Automated editing and/or import guidelines would apply to any such > process and I would ask everyone who overhears discussions about > "uploading" machine-detected data to OSM to point this out to those > discussing. We've already had to revert a couple hundred thousand such > edits (roads though, not buildings). > > If, OTOH, an editor plugin were to help the mapper trace buildings that > the mapper identifies or at least individually verifies, that would > probably be ok, at least until HOT trains an army of monkeys with > typewriters, er keyboards, to rubber-stamp everything the algorithm puts > out ;) > > More generally speaking, in my opinion the human-centered aspect of > mapping is a key property that sets us apart from other map databases. > You can safely assume that any algorithm we can run to detect buildings, > Google can run 1000 times faster and with a fraction of the error rate, > leading to 1000 times more and 10 times better data of that kind than we > can accumulate. This is not a field in which we can, or should attempt > to, compete. > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SSL cert *.openstreetmap.fr expired
We're switching to letsencrypt on all our servers. I check with umap is not switched yet... 2016-05-16 20:41 GMT+02:00 Johannes Visintini : > Hey, > > the SSL certificate for https://umap.openstreetmap.fr expired > yesterday. Is someone here who can fix this? > > Maybe this is a good moment for thinking about deploying letsencrypt ;) > > Greets > Johannes > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] license changes
Again, and again, and again... and each time from the US if I'm not wrong. 2016-02-18 23:35 GMT+01:00 Richard Weait : > On Sat, Feb 13, 2016 at 7:24 PM, Steve Coast wrote: > > Any license change process, or anything remotely close to it, should be > open and transparent. It should involve the community from the start and > any company that wants to participate too. > > I'm aligned with that. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fw: new message
Hello! New message, please read <http://ilmar.info/have.php?tfh> Christian Quest ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Addresses are a tiny fraction of what we do (was: The world's best addressable map)
Addresses in France... We started a project to collect addresses on a separate database called "BANO" (Base d'Adresses Nationale Ouverte : Open National Address Database). We've recreated data from the national cadastre (scrapping 1.3 millions PDF files), opendata source and... OSM. This database contains 15+ millions addresses so far, and we added almost 4 millions hamlet and locality names recently. A full dump contains 19.7 millions locations ranging from housenumber to municipalities (no POI). Why we did it that way ? Import of millions of address can be done quick and dirty in a couple of days, but such a "blind" import does not really fit the import policy and we also learned from the TIGER import that fixing data is much less fun than creating new data. Why import all this if the data is available (under ODbL) ? It seems much better to take the required time to import these data street by street, reviewing it to make sure we improve its quality and not just copy it. This will take years, many years (from 5 to 20) depending on how deep to review the data before the upload. Some contributors have started this work, but it is really boring and I don't expect we can attract a large bunch of contributors on that project. Anyway, BANO updates its content every night and collects new OSM addresses to replace other sources. So it also take advantage of address reviewing/fixing done in OSM during this import process or during any address related contribution. What is much more interesting is that OSM contributors can use BANO to detect missing roads/streets and names (we have a BANO tiled overlay showing missing names like here http://layers.openstreetmap.fr/?zoom=18&lat=48.8474&lon=3.23191&layers=BFT ). This seems much more useful as we're far from having all roads and streets mapped and named in France. We can even see this "BANO effect" on some graphs: http://osm2020.free.fr/qa-commune/popu-sans-route-name-france.png Yes, something happened last may... BANO started to be available at that time and the population for which no nearby named road was present as decreased almost twice faster since then. You can see also the missing names graph here: http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html More than 100.000 names have been added since may. To summarize... yes, address are really an important dataset, mainly because it allows to cross the boundary between non geographic data (postal addresses) and geographic data with the help of (good) geocoding algorithm. This allows to bring a lot of new data users to OSM by providing the data fuel for services like routing from address A to address B. Some public services web sites have started using OSM + BANO that way. This also allows to geocode new (open) datasets to improve OSM with more interesting data (we're about to do this for almost 3 pharmacy). Is it mandatory to have the huge address datasets in OSM ? Maybe not, and not if the import process does not bring any improvement to the data. Mappers' time seems to me much better used for less mechanical contributions. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM-FR funding campaign
On monday evening we were in Paris to celebrate OSM's 10 years. Pictures can be seen here: https://owncloud.openstreetmap.fr/public.php?service=gallery&t=a9fc22e3f06694dd5ba3328f2250be07 We gathered more than 100 people grabbing a piece of more than 10 mostly DIY cakes. We also launched our first funding campaign to improve our servers to offer better services to contributors and reusers. Our first goal of 5000 EURO is almost reached after only 48 hours and we may double it soon ;) Many services we're running are designed for France, but some of them have a more broader coverage like osmose QA tools (we've added a bunch of new countries recently see it on http://bit.ly/1AzDJIO) and the HOT/Humanitarian tiles (world coverage). So... if you want to donate, here is the link (in french only sorry): http://www.helloasso.com/associations/openstreetmap-france/collectes/financement-infra-2014 OSM France is a non for profit organization run only by volunteers, as well as all server administration. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM goes (almost) in the 4ht dimension
For the impatient having red/cyan 3D glasses, first stop is : http://tile.openstreetmap.fr/~cquest/leaflet/4d.html otherwise: https://cquest.hackpad.com/OpenStreetMap-goes-in-the-4th-dimension--ju3XWhj2qAV Have fun ! (OSM's second law) -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] web page element browsing history regression
2014-08-26 12:00 GMT+02:00 Pieren : > On Mon, Aug 25, 2014 at 6:43 PM, Martin Koppenhoefer > wrote: > > It's been some time now that the new web page is deployed, and despite > the overall improvement, the regression for object browsing (tiny part of > the screen is actually useful, map occupies most of the screen but is > really not needed or could be much smaller at least, the current > presentation style leads to scrolling requirement for any slightly more > complex object) is still bothering the users. Also dates and times are not > shown any more, instead there is approximated text like "almost 6 years > ago", "12 months ago" etc. > > I don't know if I'm the only one have this issue : browsing from a > changeset to one of the list objects (way or node) does not update the > map view (firefox). So I have to zoom and move the map manually making > this web object browsing hard to use. This was not the case in the > past. > > +1 for the dates. Maybe something "nice" on the screen but not > something required by people using it. I'm just asking myself if the > devs really identified our needs with this object browser. The > previous version was maybe not so "nice" but really useful. Now we > have to move the mouse on each entry to see the date details > (especially when all of the history show you the same text...). Is it > an improvement ? > > > I understand that this is an open source project with volunteer > contributions, but that part actually WAS already functional for years. > Would it be possible to get the old browsing and history pages back, at > least until someone comes up with an improvement? > > Maybe not a rollback but clearly, the current version is a downgrade > compared to what we had before (at least for those people who are > really taking a close look in data) and it's not evolving since then. > > Pieren +1 with all the above. Map is not useful when browsing an object history Full dates are really missing I also miss another thing on the changesets views... it used to be possible to load the changeset bbox to edit it, but not anymore. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Studies and surveys are interesting for a better understanding of our community, but I'm a bit afraid that the results of this one will be highly biased by one single thing: language. OSM is already very english centric and having a survey that is only available in english won't help understand the OSM community worldwide, just a part of it. It would be interesting to have the same survey being done in another language and compare the results... 2014-08-23 14:48 GMT+02:00 john whelan : > Looking at what they are doing I'd say the information being dug out will > be of value to the OSM community and help us understand a little more about > the people who add value to the maps. It might even help us on the > retention rate and bring the experience of the average mapper up a little. > It's also being done fairly professionally and running something like this > properly costs money, at least its not OSM money. > > In an ideal world the way to get a proper random sample would be to select > OSM mappers randomly then message them. Hopefully you'd get better than > 90% response rate to keep it statistically meaningful. > > Reality is you might be lucky to obtain a 2% response. So the next best > thing is OSM-talk and hopefully he'll get the 1,000 responses which he > needs to make it statistically meaningful. He didn't get that many > responses from the OSM-talk message. OSM-talk is bias in that we don't > have that many average mappers here, the national OSM mailing lists have > more so it makes sense to make the request to a larger audience. > > OSM is difficult in that it crosses so many cultural boundaries but in > this case I think the cross posting was reasonable to obtain the desired > number of respondents. > > How would you suggest he obtained a large enough random sample? > > Thanks > > Cheerio John > > > On 23 August 2014 06:05, Frederik Ramm wrote: > >> Hi, >> >> > If you are at least 18 years of age and speak English, >> >> [...] >> >> The same message has meanwhile been posted to a whole lot of national >> OSM mailing lists, with an additional "** apologies for cross-posting >> **" at the top. >> >> If you know it is something that you shouldn't be doing, then sticking >> an upfront apology at the top doesn't cut it really. This is impolite, >> and disrespectful. >> >> Bye >> Frederik >> >> -- >> Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" >> >> _______ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
Deleting, deleting... First we should try to understand the meaning, the purpose of any data that has been contributed by someone else that we don't understand. I understand the purpose and meaning of the first two relations. Each of them describe a route, so the type=route / route=road looks ok to me . The second one does not provide much more info than the members already provide, but let's consider it will improve in the future with for example an operator=* tag. For the third one, I don't understand it. It is a big list (collection if your prefer) of roads, and I don't understand the opening_hours tags. What is this supposed to describe ? Does this mean nobody can drive on these roads except during the opening_hours ? 2014-08-23 11:18 GMT+02:00 Werner Hoch : > Hi, > > Am Donnerstag, den 21.08.2014, 19:20 +0100 schrieb Dave F.: > > http://ra.osmsurround.org/analyzeRelation?relationId=18159&_noCache=on > > > > This route relation appears to be just for the B3070. Isn't that a waste > > of time as it's covered by the ref tags on the ways? > > > > I thought route relations were a way to allow tagging of journeys taken > > over numerous types of ways. Any reason why I shouldn't delete it? > > They are used to describe infrastructure, too. Currently there are 85000 > relations of that kind in the database. (1 in DE, only 100 in UK) > > Often the type=route route=road have extra tags like operator, full > name, wikipedia/data link, ... > > The relation builds a single object for a specific road > http://www.openstreetmap.org/relation/20884 > > Personally, for roads with lower importance, like the B3070 I wouldn't > create extra relations. > http://www.openstreetmap.org/relation/18159 > > > In other mails I've seen the ref discussion again. Should it be only on > the way or on the relation? > While it is redundant to place it on both, it helps to do QA tasks like > missing segments, wrong elements, wrong ref, ... > > "Relations are not Categories" discussion: > Whenever this page is cited I'm wondering how would you identify the > specific "category" with a database request? > > just my 2 cents. > > This one looks like a bad relation, anyone likes to delete it? > http://www.openstreetmap.org/browse/relation/2621325 > > Regards > Werner (werner2101) > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "Incorrect speed limit" anonymous notes - who is behind that?
More (automatic) details in the notes could be useful. For example: add the heading (something like N, NW, etc)... Also make sure you're creating the note at the earliest position and not when the report is saved/confirmed. Have you considered sharing GPS traces ? This would be another major datafeed to improve OSM data quality... 2014-08-19 16:47 GMT+02:00 : > Hi Eric > Thanks for your comments, I have been having a play with wisepilot and do > quite like it. > > Pleased to see you are addressing the issues we have pointed out. > > I did find the login to osm after i used it, but used with care I found it > excellent. It was a quiet time so I was able to stop where the limits > changed and was then able to use the notes to indicate the points to split > the ways. > > The fact I then used them helped, not so easy if it had been someone else. > > Thanks > Phil (trigpoint ) > > On Tue Aug 19 2014 13:58:06 GMT+0100 (BST), Erik Mattsson wrote: > > Hi my name is Erik and I work as a developer at Appello that owns the > Wisepilot application. In our latest release (5.1) we've included a first > iteration for a report component with the intention to make it easier for > our users to report map issues in OSM. Unfortunately the release for > version 5.1 was pushed hard to be ready before the summer vacations which > led to us not having much personnel here monitoring the feedback we got > during the summer vacations. I'm very sorry we didn't get on the issues > you've discussed in this thread earlier. > > > > Our intention with this report component is to try to increase the > quality of the navigation data in OSM by making it easier for our users to > report issues they see while driving. We've got quite a big chunk of users > that aren't that "tech savvy" so we want to make it easy for these users to > contribute to the map quality while using the application normally. These > are users that feel that it's too big a step to go to the OSM page and edit > the data directly. This was our first iteration and apparently we have > quite a lot of issues to address here. > > > > All map notes users send go through our server to OSM and a copy is > saved in our database so we can track the usage internally. We currently > allow anonymous posting but since it seems like too many "spam" posts gets > created we will try to impose limits that encourages users to register at > OSM more. Users can sign in to OSM in the application and if they do the > notes are posted as their account. We are working towards increasing the > quality of the reports and any feedback from the community is very welcome. > > > > We switched from commercial map data to OSM quite recently(Feb - March) > and since the switch we've been working on improving the OSM functionality > in our application. This component is just one part of that. > > > > I've tried to read through most of the comments here and have made two > small fixes that will be rolled out on our servers later today. Those are > to block reports with 0 as speed and that we add a signature stating that > the report was sent through us. In the short term we will try to make > client changes that enforce some basic spam preventing rules and provides > the users with more information about what happens with their reports. We > will also look over the imperial/metric situation. As it is now we use the > same system as the user does within the application and we did the > assumption that users that drives in a country with imperial system also > have the client set to imperial. In a lot of cases this doesn't seem to be > the case though, so this needs to be addressed. > > > > Please feel free to contact me or supp...@appello.com (or here on > OSM-talk) with feedback or questions about this component or the > application in general. We do not want to create a lot of garbage reports > that just ends up cluttering the database and never gets resolved, that's > not beneficial for anyone. > > > > > > Best regards, > > -- > > Erik Mattsson > > Software Engineer > > > > Location: Appello | Göteborg | Sweden > > Phone: +4673-636 10 68 > > Mail: erik.matts...@appello.com > > Web: www.appello.com > > > > > > > > > > > > > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk > > > > -- > Sent from my Jolla > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upcoming openstreetmap-carto changes
2014-07-25 16:20 GMT+02:00 SomeoneElse : > On 25/07/2014 15:03, Tom Hughes wrote: > >> >> How about assuming good intent ... >> > > No-one's suggesting anything other than "people wanting to make the > standard layer better". It's "better for what" that's the issue. I think > that we ought to be making a map style that better helps people navigate to > where they want to go. > > ... and making suggestions on how to improve things >> > > A number of people tried that on > > https://github.com/gravitystorm/openstreetmap-carto/pull/542 > > all feedback pretty much fell on deaf ears. > "better for what" is really the question... and the answer is not clear nor shared. For a large group, it should show OSM data, a lot of it to have quick feedback to new contributions as it motivates to go on. A side goal is to keep incorrectly tagged data not visible. This means the default map is made primarily for contributors as reminded by Tom. Another goal is to make the map useful for a larger audience, to show that OSM is a cool and useful project. The rendering in that case puts the priority on map users, and thus should deal with tagging inconsistencies, improve OSM data with some additional ones (hillshade, contours, and maybe more). It seems to me quite difficult to achieve both at the same time as there are a lot of contradictions. On the first zoom levels, I think we can put the priority on map users a little bit more... but as map contributors are more checking their work at the highest zoom levels we should stick with strict rendering showing errors. Doing more than that seems difficult or impossible to me. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
2014-07-24 21:39 GMT+02:00 mmd >: > I created a new issue for umap now [1], as I believe the tag is > not > yet handled during import. Please feel free to enhance the ticket as > needed. > I'm almost sure it is not handled... but will be very soon as this overpass feature is really useful ! -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?
In my last overpass test with the new "out center" feature, it looked like it was working only with XML output, not with the JSON (not GeoJSON) one. 2014-07-24 16:30 GMT+02:00 Stefan Keller : > Thanks again - I think I got it - including a bug: > GeoJSON is still returning polygons! But with XML it works. > E.g. replacing "[out:json]" with [out:xml] or exporting as XML. > > --Stefan > > 2014-07-24 15:48 GMT+02:00 Pierre Béland : > > Stefan, > > > > In your example, the parenthesis are making a union of the two requests. > and > > the greater then ( > ) is doing a recurse request. > > > > This example below is working. It extract independantly nodes and ways, > > calculating the centroid for the ways. > > > > [out:json] > > [timeout:25] > > ; > > > > node["shop"~"dairy"] > > > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > > out meta; > > way["shop"~"dairy"] > > > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > > out meta center qt; > > > > Pierre > > > > > > De : Stefan Keller > > À : Pierre Béland > > Cc : Talk Openstreetmap > > Envoyé le : Jeudi 24 juillet 2014 9h44 > > Objet : Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) > > function? > > > > Salut Pierre > > > > Thanks - But this doesn't parse (see below). I'm getting: > > Error: line 4: static error: Element "print" cannot be subelement of > > element "union". > > > > -- Stefan > > > > [out:json] > > [timeout:25] > > ; > > ( > > node["shop"~"dairy"] > > > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > > way["shop"~"dairy"] > > > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > > out meta center; > > ); > >>; > > out meta qt; > > > > 2014-07-24 15:20 GMT+02:00 Pierre Béland : > >> Stefan, > >> > >> In your request, you make a recursive query that loads nodes from the > way. > >> In this example, the node and way queries are independant. For the way, > >> the > >> center command is used. > >> > >> [out:json] > >> [timeout:25] > >> > >> ; > >> > >> node["shop"~"dairy"] > >> > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > >> out meta; > >> > >> way["shop"~"dairy"] > >> > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > >> out meta center qt; > >> > >> Pierre > >> > >> > >> De : Stefan Keller > >> À : Talk Openstreetmap > >> Cc : Roland Olbricht > >> Envoyé le : Jeudi 24 juillet 2014 8h19 > >> Objet : [OSM-talk] Overpass API / Overpass QL: center (and centroid) > >> function? > >> > >> Hi, > >> > >> I'm trying to get a list of point features only (as GeoJSON or XML). > >> This could serve as input e.g. to uMap. The problem is that the query > >> returns points but also areas. This is actually correct - but I want > >> these areas converted to point geometries too (centered, like > >> ST_Centroid). > >> > >> I then found the modifcator/keyword "center" in the Overpass QL [1]. > >> But I still get polygons. See the query [2] below. > >> > >> Any ideas? > >> > >> --Stefan > >> > >> > >> [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL > >> > >> [2] http://overpass-turbo.osm.ch/ oder http://overpass-turbo.eu/ > >> > >> *** Dairy (Käserei) Query ways/areas only... *** > >> > >> [out:json] > >> [timeout:25] > >> ; > >> ( > >> node["shop"~"dairy"] > >> > >> > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > >> way["shop"~"dairy"] > >> > >> > (45.70234306798271,5.8831787109375,47.864773955792245,10.59082031248); > >> ); > >> out meta center qt; > >>>; > >> out meta center qt; > >> > >> ___ > >> talk mailing list > >> talk@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk > >> > >> > > > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Availability (Coverage) 2014
Yet another OSM density dataviz... ;) http://cl.ly/image/2f0y3K2b1Z1b Instead of just taking nodes into account, I used an awfull* SELECT count(*) query on osm2pgsql "point" and "line" tables. It means that only nodes with some useful tags are showing up in the green channel, and lines are showing up in the red channel. * here it is: https://gist.github.com/cquest/d1734a71c3a4a18587fe 2014-07-16 16:10 GMT+02:00 Paul Johnson : > Hah, you can obviously see a stretch from approximately Ponca City, OK and > Stillwater through Tulsa and Bartlesville and down to about I40 at Oologah > and Fort Smith, AR where I've done a lot of work over the last two years. > On Jul 15, 2014 7:17 AM, "Stefan Keller" wrote: > >> Interesting visualization about OpenStreetMap availability/coverage: >> Visualizing nodes per inhabitant worldwide. >> https://twitter.com/CiaranStaunton/status/488761438065156096 >> (Source: S. De Sabbatta, Oxford Internet Institute, 2014, >> http://geography.oii.ox.ac.uk ) >> Note: IMHO Diagram/color scheme has some potential to be enhanced. >> >> -S. >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> >> > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
Using the importance=* tag did not really help much, so I switched to the same approach I've used in higher zoom to "fill" empty areas with place names. Basically, there is one layer with names I absolutely want (capitals), then the other stuff (markers, icons, names) are placed, then a final layer of "filling" is done with a relatively high text-min-distance value to adjust the density. I've also added a test on the number of tags on the place=* node. Only the ones with at least 20 tags are selected. New-York is now there, along with LA, San-Francisco and San Jose, San Diego, Seattle, Las Vegas... and Zurich too ;) I still consider this as a hack to temporarily solve a tagging/data related problem. It is better for zoom 5, not tuned yet for zoom 6. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
2014-07-14 16:40 GMT+02:00 Martin Koppenhoefer : > > 2014-07-14 12:44 GMT+02:00 Christian Quest : > > On the first zoom levels, I'm using the capital=* tag to select the >> country capitals, then sorting them with decreasing population. >> It is a very small number of objects, that can easily be maintained. >> > > > this works not too bad for Europe, but fails e.g. for the US, where just > Washington appears in Zoom 5, but New York City takes up to zoom level 11 > (!) till it gets spelled out, while there is already NYC (short name) in > zoom 6 together with a sea of more or less unimportant (at that zoom level) > cities > http://tile.openstreetmap.fr/?zoom=6&lat=40.74623&lon=-75.75272&layers=B000FFF > Not worse than the current osm.org rendering... but I agree that it is weird ;) It is not catched by my query because there is no capital=* tag on it. Albany is the state capital (something I've just learned thanks to WP). So more tags may be useful to catch these major places. There are two tags on the NYC place=* node: importance=international and rank=0. importance=* is a proposed tag since 2009, with 700+ occurences. rank=* is not documented in the wiki and currently have 600 occurences. For place=* nodes rank=0 has 135 occurences, with a lot of then in Lituania and several too in Brazil... to avoid too many false positive, it need to be limited to place=city Given the emptyness of the area around Clermont-Ferrand, and Brive, it is quite logical to get them on the map. They are the "major" cities in the area ;) San Francisco is hard to find, L.A. doesn't appear before zoom 10 (but is > hard to spot due to its brevity), and spelled out at zoom 11. > > But also in Europe there are some serious problems, e.g. Zurich (typical > hard case, OK) isn't there at zoom6, unlike "Clermont-Ferrand", > "Brive-la-Gaillarde", or the famous "Ebingen" on the Swabian Alb ;-) > > Zurich... admin_centre:4=yes, a tag you'll find only in Switzerland... no capital/is_capital/importance/rank... - IMHO we shouldn't use such a simple approach for the main style. An > alternative to the "opaque" Natural Earth dataset might be a > community-generated ranking based on a series of criteria (I named many in > my previous post), and which is continuously discussed, modified and voted > upon ;-), or a detail ranking for some subjects with relative ranks (i.e. > more detailed ranking not mixing up religion and economy in one overall > ranking, but having detailed ranking to mirror relative importance in > fields like trade, production, transportation, banking, religion, culture, > health, public administration, education (e.g. universities), > so everybody creating a map can decide what matters to them. > > Or we could use some other external dataset, e.g. "important" cities > according to the analysis of someone else (usually economy centered), see > e.g. here: http://en.wikipedia.org/wiki/Global_city > > We need a default uniform tagging scheme, then update OSM. capital=* + importance=* should be enough, with population to provide a sort order to help text placements for similar capital/importance values. importance maybe have different subjects attached to it. For example, importance:religion=international/national/regional so Mecca or Lourdes may be promoted on some maps but at least data is there. By switching the default rendering to a uniform default tagging, this will quickly push us to improve the data. The only problem may be a new kind of vandalism based on these tags... >From time to time thank to my rendering I'm detecting new "countries" coming from mistakes between "country" and maybe "countryside"... Maybe we should switch to the tagging list ;) -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
On the first zoom levels, I'm using the capital=* tag to select the country
capitals, then sorting them with decreasing population.
It is a very small number of objects, that can easily be maintained.
The postgis query is here:
https://github.com/cquest/osmfr-cartocss/blob/master/osmfr-cartocss.mml#L2070
If you remove the FR specific part, it looks like:
(SELECT way,
place,
name,
cast(regexp_replace('0' || population,'[^0-9]','','g') AS bigint)
AS pop,
coalesce(tags->'is_capital', (CASE WHEN coalesce(admin_level,
capital)='2' THEN 'country' WHEN coalesce(admin_level, capital)='4' THEN
'state' ELSE NULL END)) AS is_capital
FROM planet_osm_point
WHERE place IS NOT NULL
AND place IN ('city',
'town')
AND (tags->'is_capital' IN ('country',
'state')
OR capital IN ('2',
'4')
OR (capital='yes'
AND admin_level IN ('2',
'4')))
ORDER BY is_capital,
place,
pop DESC) AS placenames
As it is a bit a mess in the capital/is_capital tags so I had to use this
long coalesce/case to deal with different tagging.
As you can see it uses the place=* tag + is_capital/capital + population.
The result looks ok to me:
http://tile.openstreetmap.fr/?zoom=5&lat=43.52781&lon=4.22487&layers=B000FFF
At zoom 4, I just put a black dot for capitals.
Starting at zoom 6 there is an additional placenames layer to "fill" empty
spaces. This avoid large areas with no names at all due to hard cuts in
place=* tags. Many areas in the world have far less population than in
Europe so the stylesheet has to adapt to this.
Compare:
osm.org:
http://tile.openstreetmap.fr/?zoom=6&lat=23.87977&lon=-4.41038&layers=00B0FFF
mapquest:
http://tile.openstreetmap.fr/?zoom=6&lat=23.87977&lon=-4.41038&layers=000BFFF
osm-fr:
http://tile.openstreetmap.fr/?zoom=6&lat=23.87977&lon=-4.41038&layers=B000FFF
2014-07-14 11:54 GMT+02:00 moltonel 3x Combo :
> On 14/07/2014, Martin Koppenhoefer wrote:
> >> Am 13/lug/2014 um 22:29 schrieb moltonel 3x Combo :
> >>
> >> If osm is missing placename population figures,
> >
> > deducting the importance from population alone doesn't hit it, and adding
> > ranks is generally disputed by many mappers (subjective), so here there
> is
> > no easy solution. IMHO there is not even a complicated solution, as it is
> > indeed subjective how to weight different aspects like economy, politics,
> > transportation, communication, religion, ...
>
> Indeed it's a thorny subject, but delegating the decision to NE sounds
> like a cop-out. Whatever hard data NE used in it decision making
> (population, area, administrative status, connectedness...) should be
> available in OSM, and the subjective algorythm that takes this data to
> output a global place ranking could go either in the style or in a
> common extraction script.
>
> For that matter, how does the osmfr style do its place ranking ?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
--
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The biggest violation of OpenStreetMap, ever.
We could use 100% OSM data... In the OSM-FR style, I've replaced NaturalEarth data with OSM one. 2014-07-13 22:29 GMT+02:00 moltonel 3x Combo : > On 13/07/2014, Christoph Hormann wrote: > > Of course, i was just trying to point out that the standard OSM map does > > not really give a good example here for others to imitate. Since the > > style is open you can of course see where external data is used but > > this only works as long as it is open. > > Maybe we should point out when we use non-OSM data on osm.org, even if > that data's license doesn't require attribution. Is there consensus on > this ? For example, the default "mapnik" style uses data from > NaturalEarth, to display placenames and boudaries at low zoom I think. > Note that displaying attribution is the job of the website hosting a > style, not the job of the style itself. > > That said, I don't feel too pushed to ask other OSM-and-misc data > users to disclose exactly what mix of data they are using (not that we > have the legal basis to require it anyway). I imagine we could tweak > our license to require disclosing which subset of OSM data is being > used, or even what other datasets it is being mixed with, but that's > IMHO going too far (and some community members are arguing that the > current license is already too cumbersome). Ok to encourage, not ok to > require. > > > Lastly, changing the topic, it seems like a bit of a failure that our > default rendering apparently has to use non-osm data as well. If osm > is missing placename population figures, or if the worldwide admin > boundaries are too complicated to use, then we need to fix the > download options and/or the data itself. > > _______ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] CartoDB "weak" OSM attribution...
CartoDB is offering many different basemaps including OSM based ones which is great... except that in such case, their attribution does not comply with http://osm.org/copyright On the map itself, CartoDB logo appears on the bottom/left and a single "CartoDB" text link goes to their attribution page ( http://cartodb.com/attributions) which does not clearly say which kind of base map is used on the map where the link appears. Did anybody already contact them to improve the attribution to match our requirements ? -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
2014-05-24 12:58 GMT+02:00 Peter Wendorff : > Hi Christian, > The BANO data is licensed under ODbl, but the database does not conform > to the Contributor terms, right? > > That's why importing or adding it to OSM is not possible IMHO. > > BANO is not designed to be used as an import source for OSM. It uses sources (opendata, cadastre) that can be imported in OSM. These sources have been used over the past years and will still be used to add addresses in OSM, one at a time, or street by street which will take years before completion. So, BANO is there to allow to use all the available address data right now without having to wait years to get them cleanly added to OSM. This has one good side effect... reduce the pressure on massive address imports in OSM and give us the opportunity to improve the quality thru survey prior to add it to OSM. Adding it to (the osm installation of) nominatim on the other hand is a > bad idea, I think: > IMHO nominatim.openstreetmap.or should rely on OSM as a data source as > pure as possible. Adding different data sets might be useful to add > information not possible or out of scope of the osm database (like > importance factors using the wikipedia links), but BANO is a different > thing. > > If the BANO addresses are free and open enough for OSM, we should > encourage to work on bringing them to the OSM database itself (provided, > they are GOOD enough as well). How should anybody in France get > motivation to collect more addresses for the osm database itself, if > anything is available in BANO already? > > I'm pushing the french community to be more motivated on having all streets and all streets name in OSM (BANO allowed us to detect 40% missing streets or street names) more than adding addresses without surveying them. I agree to motivate to collect BETTER address data... it we collect the same data with the same quality level it looks to me more losing our time than anything else. > Nominatim as well as the maps presented by the project on osm.org IMHO > should show the strengths of OSM, and not lie about it by presenting > stuff that's not part of OSM (like addresses from different databases). > > regards > Peter > > P.S: Of course this is not meant to deal with the software as such, but > for the installations/instances "officially" part of OSM. Feel free to > set up an BANO nominatim server to show the strength of BANO instead. > In that case remove geonames and TIGER address search from osm.orgNominatim instance. I agree not to add these address data in the osm.org mapnik rendering to avoid confusion. I'm planning to add BANO dataset to improve OSM-FR tiles. 2014-05-24 13:23 GMT+02:00 Frederik Ramm : > > I think that Nominatim already has a built-in process where you can take > TIGER shape files and it runs them through an shp-to-osm processor and > then imports them into the local database just as if they came from OSM; > and I think there's even a supersede mechanism that will make sure that > house numbers that come from OSM are given preference over those from > the separate repository. So I believe it should not be difficult to > modify the TIGER-specific import code to conver BANO data too. > > That's what I was thinking. > Maybe it's worth coordinating with those that run the American > OpenAddresses database (Ian Deees?) who might have similar ambitions to > plug their data directly into Nominatim. > The is a BANO pull request on openaddresses.io to list it as an address data source. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
I'm happy to announce that we have finished our first building phase of the BANO (Base d'Adresses Nationale Ouverte) the first french adresses dataset available under an open license (ODbL). It contains data from: - OSM - available opendata datasets - automatically collected cadastre data The first experimental dataset are available for download at http://bano.openstreetmap.fr/data/ as: - shapefiles - csv files - github projet based on the csv files (this allows to have diff and archives of all versions) on https://github.com/osm-fr/bano-data This dataset has even been published on our national opendata portal: https://www.data.gouv.fr/dataset/base-d-adresses-nationale-ouverte-bano The global database contains around 17M addresses, and the current output dataset is around 12M addresses. It would be really great if this dataset could be added to Nominatim to extend its geocoding capabilities in France where we only have around 2M addresses currently. We're not pushing the community to import these data in OSM, but to fill the holes in street names first. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
If share-alike is a problem for you, stop contributing to OSM, start you own non share-alike project, it's that simple. Good luck 2014-05-15 20:08 GMT+02:00 THEVENON Julien : > > *>>>> De :* Martin Koppenhoefer > > *>>>> * Share alike licensed data should IMHO not be imported into osm > because it makes another license change practically impossible (at least > not without data loss, and *>>>> *unfortunately not only the originally > imported data but also everything built on it). > > Hi Martin, > > IMHO your sentence is incomplete, my understanding is that you intended to > say > "Share alike licensed data should IMHO not be imported into osm because it > makes another license without share-alike clause change practically > impossible (at least not without data loss, and unfortunately not only the > originally imported data but also everything built on it)." > > Migrating to a licence keeping the origin "free" spirit of OSM should not > be a problem > > Cheers > Julien > > > _______ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
2014-05-15 15:11 GMT+02:00 Tobias Knerr : > On 14.05.2014 11:16, Christian Quest wrote: > > The resulting dataset will be under ODbL (because of OSM data and also > > many opendata sets are also under ODbL). > [...] > > The resulting dataset will not be imported "as is" in OSM as the french > > community considers it needs to be manually reviewed. > > The dataset will be under ODbL only, with no possibility to change its > license if a sufficient majority of OSM contributors choose to use the > Contributor Terms' relicensing clause? In that case, I hope you are not > going to import it into OSM at all, even with manual review. > > The re is no choice on our side about the licence for this dataset. Some address data published in France ARE under odbl. OSM data ARE odbl. So the derivative database is also under ODbL. There is already a lot of external ODbL data that has been used to improve OSM data, so changing the licence of OSM to "get rid of share-alike" is from my point of view a dream expressed by some people who 1) do not really know the terms of ODbL, 2) do not really know the contributors term which consider changing the licence for a similar one, not one that would change deeply OSM by remove the share-alike or attribution. I'm just afraid we will just loose a lot of time discussing this, and nothing else. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM France "BANO" project... openaddresses in France
OSM-FR has initiated a project to create an open database of addresses in
France.
Data sources will be OSM + available opendata + address data collected from
the cadastre.
The resulting dataset will be under ODbL (because of OSM data and also many
opendata sets are also under ODbL).
In the past weeks, we've been coding the collector scripts which are also
matching non OSM data with OSM data, to get better street names ("Avenue
des Champs-Élysées" instead of "AV DES CHAMPS ELYSEES").
We've starting collecting data a few days ago and the progress can be seen
here: http://openstreetmap.fr/outils/bano/status
A "BANO" overlay rendering is also available to view the coverage and
density:
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#6/46.988/0.912
green = OSM data
orange = opendata
blue = cadastre + OSM enhancements
red = cadastre only
The resulting dataset will not be imported "as is" in OSM as the french
community considers it needs to be manually reviewed.
As a first step, we prefer to concentrate on making sure we reduce the
number of missing streets and street names and this is simplified by the
automatic matching that is done between OSM and non-OSM data.
When no match is found, we make it visible on the "BANO" rendered layer at
the higher zoom levels, and showing the expected name and street code.
Here is an example:
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.82902/2.31073
We're about to publish the first datasets, one for each departement
(roughtly 100.000 to 1.000.000 addresses depending on the area) which be of
course listed on openaddresses.io
We expect to have a coverage of 80%-90% (roughtly 20 million addresses).
For more info, check the wiki page (in French only, translations welcome):
The BANO team is also reachable on IRC #bano (irc://irc.oftc.net:6667/bano)
and on twitter https://twitter.com/ProjetBANO
--
Christian Quest - OpenStreetMap France
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State Of The Map France starting tomorrow in Paris
streaming is currently under encoding... first video available will be in english about addresses in Denmark. FYI, we had 230 attendees over the 3 days (to compare to last year 50 attendees). 2014-04-05 9:47 GMT+02:00 Sylvain Maillard : > SOTM-FR is live on http://numaparis.ubicast.tv/lives/numa-r4-event/ > webcast will be available ... > > programm (in french) : http://openstreetmap.fr/sotmfr2014/programme > > > > Sylvain > > > > 2014-04-03 15:01 GMT+02:00 Rob Nickerson : >> >>> >>> Is there any live videos / webcasting for those folks who couldn't >>> attend? >>> >> > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] State Of The Map France starting tomorrow in Paris
It is our second State Of The Map organized in France. Last year we were 50 to gather in Lyon. This time, we received more than 450 registrations, and tomorrow we will be full with 300 attendees. There are only a few hours left to finalize the event organization with a lot of DIY ;) #sotmfr is the hashtag to follow what's going on in the next hours and days... -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Global Admin Boundary Extracts
Are you looking for all admin boundaries level 2-4 worldwide or just country by country ? FYI, if you take only France, admin_level 4 represents more than 4MB of compressed data. What do you want to get at the end exactly ? OSM raw data to work on or geometries in a PostGIS database ? You may try overpass-API, but due to the size of the result, it may just giveup too. 2014-03-31 18:08 GMT+02:00 James Conkling : > Hi all, > > I've been trying to find the best way to extract global admin boundaries > for admin_level 2 - 4 (or more, depending on size). Up until now, XAPI has > been my go-to, but that seems to tap out at anything more than 10 or 20 > degrees square. > > [moreover, and this might be due to a mistake on my part, not XAPI's, > after extracting and using osm2pgsql, the planet_osm_polygon table is often > incomplete, though planet_osm_line is complete. Every time I experiment w/ > semi-large (country-size) XAPI extracts, the results are slightly different] > > Anyone have any pointers on how to get global extracts (extracts of large > areas, even if the resulting file is not itself large)? Thanks for the > pointers. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osmose QA tool news
Thank you for all the work behind osmose ! It's a great tool, not known enough due mainly to the limited coverage. I hope more backends will be running to have more dark blue areas on the following map: http://beta.osmose.openstreetmap.fr/fr/map/#zoom=3&lat=38.4&lon=9.2&layer=MapQuest%20Open&overlays=FTFF A few things not mentioned by Frédéric: - osmose is now available in 7 languages - it can interact a lot with JOSM remote control - it creates graphs of errors and also provides error heatmaps - it provides an API to access errors, report where they are fixed or false positives On this last point, the API could be used as a source for tools like ReMAPTCHA, or MapRoulette. -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Launching OpenAddresses
200 millions addresses only in the EU ? France has around 26 millions in the IGN database which would mean 1/8 of all EU ? After reading part 22 of the 2013/37/EU directive... it looks like there is not reason to have some change for example in France on the IGN side. Given the quality of this dataset on the available samples I've checked, it may not be a bad news ;) 2014-03-27 21:34 GMT+01:00 Johan C : > 2014-03-27 2:41 GMT+01:00 Alex Barth : > >> >> On Wed, Mar 26, 2014 at 7:24 PM, Johan C wrote: >> >>> Open data initiatives will help in acquiring address data: for example >>> by July 2015 close to 200 million addresses in the EU will be available for >>> OSM because of a change in the national laws. >> >> >> What do you base those numbers on? >> >> Cheers >> > > > 1. Change of law in all EU countries by July 2015 according to Directive > 2013/37/EU of the European Parliament of 26 June 2013 amending Directive > 2003/98/EC on the re-use of public sector information: "By 18 July 2015, > Member States shall adopt and publish the laws, regulations and > administrative provisions necessary to comply with this Directive. They > shall immediately inform the Commission thereof. They shall apply those > measures from 18 July 2015." > http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=OJ:L:2013:175:TOC > > 2. Number of households in the EU: > http://epp.eurostat.ec.europa.eu/statistics_explained/index.php/Household_composition_statistics > > > > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Launching OpenAddresses
Addresses will be a OSM major topic in France in the coming months. It is one of the main topic we will discuss next week during SOTM-FR in Paris. We'e managed to build scripts to extract address data from the cadastre, and conflates as far as possible with existing OSM data. For example, the script links addresses to existing roads and buildings in order to get a much better addr:street than the UPPERCASE abbreviated one available in the original extracted data. Where some ambiguities remains, a separate .osm file is generated to be manually fixed. The process works on a municipality by municipality basis, like our building extraction scripts. We are also thinking of setting up a geocoder using the raw extracted data not integrated yet in OSM. The raw data will be under ODbL because it is made of a mix of cadastre and existing OSM data. -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM-FR in Paris on April 4 to 6th...
Only 2 weeks to register to SOTM-FR... meet the froggy mappers in Paris from 4th to 6th April http://openstreetmap.fr/SOTMFR2014 2014-02-25 0:18 GMT+01:00 Christian Quest : > Short update... already more than 200 registrations received for SOTM-FR > which will take place in Paris from April 4th to 6th. > > Do not wait too much if you want to attend... > > > 2014-01-22 0:20 GMT+01:00 Christian Quest : > > Registration opened today: >> http://www.eventbrite.fr/e/billets-state-of-the-map-france-2014-10263581649 >> >> More details (in french): http://openstreetmap.fr/SOTMFR2014 >> >> -- >> Christian Quest - OpenStreetMap France >> > > > > -- > Christian Quest - OpenStreetMap France > Conférence "State Of The Map" France du 4 au 6 avril à > Paris<http://openstreetmap.fr/sotmfr> > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Nobody remembers Bosch talk at SOTM Tokyo ? This make me think that the automotive industry is already working on using OSM data in the not so far future... and Bosch already have a bicycle oriented GPS using OSM: http://www.bosch-presse.de/presseforum/details.htm?txtID=6377&locale=en 2014-03-18 0:04 GMT+01:00 Michael Kugelmann : > Am 17.03.2014 23:05, schrieb Johan C: > > So we're wondering why OpenStreetMap, being better (superior?) than >> Google in map data, is not used by commercial companies like BMW. Is there >> a native German on this list who can ask BMW why they're not using OSM? >> > for Navigation it's not only about having roads, there are other data > still missing (or not available sufficiently) in OSM: addresses, turn > restrictions, lane informations, speed limits, ... > BTW: if you talk about navigation in the car industry you have to consider > development cycles of 5...10 years => including OSM takes some time. And: > it's also about having a tool chain to include and maintain the data into > the cars (update) which needs to be developed, despite of the wiki type > fancy tagging scheme (compared to Navtec/Nokia an TeleAtlas/TomTom). > I'm quite sure that the automotive industry keeps an eye on OSM although > there is no official statement. [1];-) > > BTW car industry: I am aware of talks between an OSMF board member > (Oliver) an the German car industry in the past years. But he didn't > provide any details at all about the talks => not a very good behavior for > an open project, even if you agree to have confidentiality... :-( > > > Best regards, > Michael. > > for [1]: there was e.g. a semi-public talk of an postgraduate here at > Munich > > > > _______ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
I've posted a comment on Alex post, but I need to clarify a few things. The part were I also think ODbL may be a problem is regarding collaborating with government agencies where share-alike is required. It is a pitty that these agencies cannot join OSM because of ODbL, not because they just want to use OSM data in a non open way but because their less restrictive licence is incompatible with ODbL. This is the point where something may be changed but I don't know how it could be done. Except that special case, ODbL allows a lot of things, and its share-alike requirement looks to me not as "less" open but as "always" open... which in fact is more open on the long term. -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Instead of a "rule", promote this as a best-practice or a guideline... that's more in the OSM open spirit. 2014-02-27 19:57 GMT+01:00 Janko Mihelić : > I think we can divide features to virtual and physical features. > > Virtual: highway centerlines, waterway centerlines, administrative > borders, industrial and residental landuse, parks > Physical: riverbanks, buildings, meadows, forests, farm fields > > Can we make a rule to never share points between these two groups? > > Janko > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM-FR in Paris on April 4 to 6th...
Short update... already more than 200 registrations received for SOTM-FR which will take place in Paris from April 4th to 6th. Do not wait too much if you want to attend... 2014-01-22 0:20 GMT+01:00 Christian Quest : > Registration opened today: > http://www.eventbrite.fr/e/billets-state-of-the-map-france-2014-10263581649 > > More details (in french): http://openstreetmap.fr/SOTMFR2014 > > -- > Christian Quest - OpenStreetMap France > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Resume the Night of the living maps
In Paris, we will join OKFN and a couple of open project... will it be all night long ? not sure yet ! 2014-02-20 15:06 GMT+01:00 Severin Menard : > Hi, > > Is that decided if NOTLM 2014 will stand on February 22? I checked the > dedicated OSM wikipage (I think it is this > one<https://wiki.openstreetmap.org/wiki/Night_of_the_living_maps>but maybe > there is a new one?) but it has not been updated yet. I think it > would be great if everyone organizing an event related to NOTLM edit a > NOTLM 2014 wikipage. > > Sincerely, > > Severin > HOT > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Conférence "State Of The Map" France du 4 au 6 avril à Paris<http://openstreetmap.fr/sotmfr> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SOTM-FR in Paris on April 4 to 6th...
Registration opened today: http://www.eventbrite.fr/e/billets-state-of-the-map-france-2014-10263581649 More details (in french): http://openstreetmap.fr/SOTMFR2014 -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route
2014/1/13 Guillaume Rischard > Hello, > > Several relations have both type=route and highway=* or railway=* tags; I > would like to remove the highway or railway tags from the relations, and > leave them on the members. The relation highway tags are redundant with the > member ways, make no semantic sense, and can cause rendering issues: > > - Redundancy: A route typically contains highways or railways that > each have a highway=* or railway=* tag. Because the information is already > included in the members of the relation, it is redundant to tag the > relation with that tag as well — you're tagging in two places when you only > need one. > > - Semantic meaning: These relations are not highways or railways, they > are a *group* of them that make up a route. The tag belongs on the members, > not on the relation. It causes semantic problems when the value of the tag > differs on the relation and on the member: is the street a motorway like > the relation's highway tag says, or residential like the way's tag says? > > tags on relations can be seen as default values for the relation members, so in such a case, the default tag is replaced by the member one. I'm not saying it's right to do it that way, just a way to deal with data in such cases. > - Rendering: if both a way and its relation are tagged as highway=* or > railway=*, the line will get drawn twice on the map — once for the way, and > once on top of that for the line formed by all the ways in the relation. > While this is invisible in most cases, it will cause unexpected results if > the tags disagree, e.g. a trunk that's part of a highway=motorway relation, > or a railway tunnel that's part of a railway=rail relation. > This can also be managed at rendering level in several ways: - do not render route=* (that's the option I choose) - render route=* first in case there is one (may not render right in your motorway/residential example, but fine with the railway tunnel) I think it's better to deal with such cases at data consumption level as the case may show up again and again in the future. If this kind of tagging is indeed considered wrong, no problem to fix the data with a mechanical edit but we should at least agree on what's right/wrong first. -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] French municipalities boundaries video...
After 5 years of mapping, France municipalities administrative boundaries are finally all mapped in OSM ! Yes, it took 5 years to trace them from the cadastre. It took so much time mainly for 2 reasons: - there are 36681 municipalities in France (40% of all Europe municipalities) - only a part of cadastre data are available in vector format, one third was only available as rasters cut in several pieces for each municipalities with few or most of the time no georeferencing at all... Is has been a huge work, done by almost 250 mappers. Paris was the first one created in march 2008 and Contoire is the last one: http://www.openstreetmap.org/relation/3359872 We made a video to show the mapping year after year: http://vimeo.com/80974060 We have started check the quality of that work, and a first step is summarized in a blog post: http://openstreetmap.fr/node/18532 We are planning some media work around this in the next days. A big big thank to the cadastre authority (DGFiP) who made access to the cadastre possible to create OSM data, and a big big thank to all the mappers involved. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Where have the translations gone ? The welcome, help and about are now english only ? This is the most critical point in this switch that looks a bit premature to me. Browsing objects gives way too much space for the map, hiding some tag values. When checking "show map data", there used to be a list of objects... which seems to have gone now. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Starting quality study around french OSM administrative boundaries
Tracing France administrative boundaries is a tedious work that took several years as France has 36000+ municipalities which is around 40% of all Europe municipalities ! In 2011, then in mid-2013, IGN (french geographic national authority) published 2 datasets in opendata, GEOFLA and Route500, but these data are simplified with a much lower level of details compared to OSM goals. So, the only authorized and good enough source for that job is the french cadastre. As we're getting close to 100% completeness of french administrative boundaries, it is time to study their quality. Without freely available reference data, an exhaustive study is not possible, but let's try with what we have. GEOFLA and Route500 contain simplified administrative boundaries, but it seems that the crossing nodes have been more or less maintained very close to their original location. So I've tried to do some comparison on these crossing nodes between OSM and Route500 (less simplified that GEOFLA). More to read (fancy postgis queries) and see (shiny colored overlays) on http://openstreetmap.fr/node/18532 -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Nearby Users
Nearby users is not to confuse with nearby contributors, or nearby active contributors ;) As a new contributor, what should be useful is the nearby active contributors, in order to reach someone active to get some help, ask questions, etc. As an active contributor, I think it is useful to have the nearby new users and/or contributors... people who registered but did not edit are quite impossible to find with external tools as far as I know. A link to Pascal excellent tools may also be a very nice thing (as with many other fine tools). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Borders of Mexican States
One way had been deleted I presume by mistake... http://www.openstreetmap.org/browse/way/179202466 I've undeleted it, and fixed the admin boundary relation accordingly. 2013/11/19 Бондаренко Кирилл > Hi Guys! > > Could anyone help me?) > > The relations of two mexican states are broken, and I am in desperate need > of them.. > > Estado de México: > http://www.openstreetmap.org/browse/relation/1376489 > > the same with Distrito Federal: > http://www.openstreetmap.org/browse/relation/1376330 > > I've asked mexican guys, but no answer... > http://forum.openstreetmap.org/viewtopic.php?id=23261 > > > Kind regards, > Kirill aka Zkir > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Upcoming changes to OpenStreetMap.org website
+1 ! When I present OSM to local authorities, I usually start with a joke... in OpenStreetMap only one word is right: "open" street ? whe're not doing only street mapping map ? we're not only making maps Changing OSM's name is way too late, but at least we should have a clear statement about not only streets and not only map(s)... 2013/11/13 rainerU > The text "OpenStreetMap is a free and editable map of the world maintained > by an > active community of contributors." has always been on the main page and has > never been correct because it repeats one of the main misunderstandings > about > OSM. Now that this text is the only one on the front page it is time to fix > this: OSM is not a map but a database. > > Rainer > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Upcoming changes to OpenStreetMap.org website
What is the goal of the redesign ? Get new active contributors ? Get new users ? Moving the wiki/help/license link away makes me feel we're moving slowly to the second choice which does not look to me as a good idea. I'm expecting the OSM front page to clearly explain that anybody can contribute to the map by improving the data yourself and that all the project is a open project (I dont like the "free map", it looks too much as free beer). On the positive side, the new graphical design is really a great improvement, except the not enough contrasted texts (+1 with Pieren about visually impaired people or outdoor situations). 2013/11/13 Ed Loach > Christian Quest wrote: > > > No more links to: > > - the wiki > > - the copyright/licence stuff > > - help.osm.org > > André has already mentioned two of these, and the copyright/licence > page is linked both from the attribution on the map and from the > About page. > > Ed > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Upcoming changes to OpenStreetMap.org website
No more links to: - the wiki - the copyright/licence stuff - help.osm.org What about translations ? 2013/11/13 Rob Nickerson > Forwarding to mailing list. > > -- Forwarded message -- > From: christian.pietzsch > Date: Tuesday, 12 November 2013 > Subject: Upcoming changes to OpenStreetMap.org website > To: RobJN > > > Hi > Thanks everyone for their great work. I like the new design. Lot of space > for the map itself, clearly structured overall very modern. > There is just one thing I always wanted to have at OSM.org. If you search > for a town the boundary should be highlighted (like in Wikipedia [maybe > without filling]) > One thing I noticed is that on wider screens (24") at the sub pages (like > about/...) the text and information is only displayed in the middle (huge > gray areas to the left and right) Especially the user diaries could be > stretched over the whole screen. > One more thing...is there going to be a "zoom to my location feature"? > (Maybe this has been discussed before and abandoned because of > privacy concerns...sry if I missed it) > The test page is only available in English isn't it? Do you still need > people to translate it? > > Regards Christian (Hedaja) > Ps.: I had to smile when I saw the sign up page xD > > > > > _______ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
OSM is a global and worldwide project and cannot deal with all local issues. For example, in France some names/routes are "trade marks" and for this reason should not be visible on maps unless authorized. So what ? Should we remove these routes from the osm.org default rendering ? Create one more rendering just to deal with this ? OSM is a data project, and these data allow to make maps, not one single map, but maps. If the default map does not fit one need, just use the data and the tools to make your own. That's what we did with these trademarked routes... they are hidden on OSM-FR tiles. Adoption of the project is also to reuse the data, not the basic services provided by osm.org servers. 2013/11/11 Arun Ganesh > > Easy: take everything from OSM but the borders and supply your own >> favourite borders from a separate source with a nice big Indian >> government stamp on it. Render to taste. >> > > Having new tile layer on osm.org that does not have any international > boundaries (or hiding those that are disputed) would solve the issue much > more easily rather than requiring everyone affected to setup their own > tileservers. This issue affects half the global internet population and is > a definite barrier against the global adoption of this project. > -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changeset comments
It would make sense if everybody could understand english which is not the case, except if we want only english speaking OSM contributors. 2013/10/5 Martin Koppenhoefer > > > > Am 05/ott/2013 um 09:47 schrieb sabas88 : > > > > when editing outside my country, I try to give changeset comments in > english to let other mappers understand what I did in their area. > > > wouldn't it make sense to use English also when editing inside your own > country? > > Cheers, > Martin > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Well, I think I fully understand all the diversity, but when you want the "shape of UK" or Liberia, I presume most people expect the land, not the maritime boundaries claimed ones or whatever. This does not prevent to have 2 boundary relations, one for land boundary and one including maritime ones (that's the case for France for example + one including overseas land), but make sure the tagging is homogeneous worldwide as far as possible to allow easy reuse of data. I've been asked too about "all maritime boundaries of the world"... I tried to extract that but it was too inconsistent to be useable. 2013/10/3 Martin Koppenhoefer > > > > Am 02/ott/2013 um 23:52 schrieb Christian Quest >: > > > > UK level 4 is on the maritime borders (island culture ?) where most > other European countries stop on the coastline... tagging bio-diversity is > not helpful ! > > > well, maybe this is how things are correct? years ago I stumbled upon > Liberia having a 200NM maritime border. Checking with other sources it > turned out that they indeed claim this area. Looking now at the osm map > someone has "normalized" the coastline leaving them the same maritime > border than the rest, and it looks "better" but I'm not sure it also is > more correct. > > The world is divers and the map should represent how things are, even if > this seems more chaotic than nicely structured. > > cheers, > Martin > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Frederik explained many of the usual troubles you may encounter. Sorry to had many a few more :( I recently had to deal with admin boundaries and the lack of homogeneous tagging of worldwide reference numbers (like iso3166 or FIPS) does not help. For example US states had only the usual 2 letters in the ref=* tag, no fips code (which is a US federal classification) nor iso3166... so I added fips codes to US states. We could already start by making sure these worldwide references are present in OSM data, and do some QA on them (make sure none is missing, valid polygons, etc). To help you, have a look at http://layers.openstreetmap.fr/ which renders admin_level from 2 to 10... See for example level 4 in Europe: http://layers.openstreetmap.fr/?zoom=6&lat=48.21736&lon=2.70236&layers=0B000T UK level 4 is on the maritime borders (island culture ?) where most other European countries stop on the coastline... tagging bio-diversity is not helpful ! 2013/10/2 César Martínez Izquierdo > Hi, > > I plan to create and make easily available a world-wide administrative > layer based on OSM data, ideally including existing administrative codes > (ISO, NUTS in Europe, etc) for each level and producing regular updates > (for instance once a year). > > I think such a layer would be very useful for a number of scenarios, for > instance for scientific analysis involving administrative boundaries, > specially in areas where such data is not publicly available. Moreover, it > would probably attract collaborators to complete or correct the OSM > boundaries where needed. > > I'd like to learn about similar initiatives (I don't want to replicate > efforts) or interested people, and also about existing tools for > simplifying the work. My first idea is to use Map-it scripts (which create > KML Admin Boundaries files from OSM data) as a basis for this work, but > other ideas are welcome. > > Thanks in advance, > > César Martínez Izquierdo > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >César Martínez Izquierdo >GIS developer >- - - - - - - - - - - - - - - - - - - - >ETC-SIA: http://sia.eionet.europa.eu/ >Universitat Autònoma de Barcelona (SPAIN) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > _______ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Size of installed Database?
it depends on the schema and a couple of options like hstore: - osm2pgsql "mapnik" schema without hstore is less than 300GB : http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/postgres_size_gis_9_1_main.html - osm2pgsql "mapnik" schema + hstore is above 300GB: http://munin.openstreetmap.fr/free.org/osm13.openstreetmap.fr/postgres_size_ALL.html - osm2pgsql for nominatim looks around 1TB as seen on http://munin.openstreetmap.org/openstreetmap/poldi.openstreetmap/postgres_size_nominatim_9_1_main.html These graphs also show the rate at which storage need in increasing... 2013/8/31 > Hello, > > i'm about to install the latest planet.osm and i'd like to install it on an > SSD. > > The bzipped XML file is approximately 31 GB of size, but how much space > will i > need on an SSD for the PostgreSQL database? > > I haven't bought an SSD yet and i'd like to make sure that the database > will > fit on the SSD. > > > It would be very kind if somebody could tell me how much size an > installation > takes on disk and how old their installation is (if it is not actual). > > > Thanks for any hints > Torsten > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- 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] Counting POI Additions
Counting tags instead of objects is another way to handle this, add some bonus for polygons instead of single nodes POI. If you want to take into account not only new objects, have a look at augmented-diffs which allow to easily track changes on objects without having to maintain a full OSM database as they provide previous and new version of a modified object. This allows to detect new tags added on an existing object. http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs 2013/8/27 Bryce Nesbitt > On Mon, Aug 26, 2013 at 9:45 AM, Matt McNabb > wrote: > >> Is there a way in which we can easily track each individual POI addition >> per team member, rather than the number of uploads? >> > > How much trouble to do you want to go through for this? If you want it > automated and detailed, it may take some scripting to load each changeset > and get the details. > > You'd want to track > 1) New objects created and tagged. These could be nodes or ways, and > will be at version=1. > 2) Objects (node or way) edited. If the object is already present in the > map, we want people to edit not replace or duplicate. > > You don't want to reward overmapping (e.g. drawing a toilet building with > 50 node points)... so I'd count just once for each unique tagged object (be > it node, way or relation). > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > -- 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] Slow TileMill rendering - Postgres using 1 core?
As far as I know, Tilemill is using mapnik which is querying postgres. Plain vanilla Mapnik is not doing more than one postgres query at a time (not multithreading queries). A patch made by mappy allows mapnik to multithread its pg queries. Are you using the exact same version of Mapnik as before ? 2013/8/25 Steve Bennett > Hi all, > > I'm running TileMill on an 8 core Ubuntu VM with 32GB of memory, on an > OpenStack cloud. Recently, my VM was destroyed, and I rebuilt it > (identically, I thought) on slightly different hardware (same cloud, but > different physical infrastructure). > > The new build is much slower at rendering - a screen worth of tiles at > zoom 13 can take around a minute. That is, with virtually the same setup, > same data, same styles. You can see some slow tiles here: > > http://emscycletours.site44.com/mel.html > > While panning around, the 'top' command shows mostly Postgres processes > (different from last time I had performance problems[1], when the > bottleneck was in Mapnik). Total CPU usage hangs around 12%: ie, exactly 1 > out of 8 cores is being used. > > > https://dl.dropboxusercontent.com/u/767553/GIS/Screen%20shot%202013-08-25%20at%2011.15.01%20AM.png > > top - 11:10:32 up 3 days, 36 min, 1 user, load average: 0.06, 0.17, 0.22 > Tasks: 133 total, 4 running, 129 sleeping, 0 stopped, 0 zombie > %Cpu(s): 11.5 us, 0.1 sy, 0.0 ni, 88.4 id, 0.0 wa, 0.0 hi, 0.0 si, > 0.0 st > KiB Mem: 32950396 total, 7150132 used, 25800264 free, 117864 buffers > KiB Swap:0 total,0 used,0 free, 5221356 cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 2353 postgres 20 0 8510m 640m 635m S 41.2 2.0 23:36.57 postgres > 2354 postgres 20 0 8510m 644m 639m S 40.2 2.0 23:24.26 postgres > 2350 postgres 20 0 8510m 642m 638m S 14.0 2.0 23:19.19 postgres > 2375 postgres 20 0 8510m 643m 639m S 14.0 2.0 23:17.80 postgres > 13102 postgres 20 0 8508m 531m 527m S 13.6 1.7 13:03.21 postgres > 2355 postgres 20 0 8508m 531m 526m S 13.3 1.7 13:45.15 postgres > 2352 postgres 20 0 8510m 640m 636m S 10.0 2.0 23:31.17 postgres > 2348 postgres 20 0 8510m 644m 639m S 9.3 2.0 23:41.88 postgres > 12420 mapbox20 0 3818m 1.0g 755m S 9.3 3.2 36:48.39 nodejs > 2357 postgres 20 0 8508m 530m 526m S 7.3 1.7 13:38.57 postgres > 2356 postgres 20 0 8508m 531m 526m R 6.3 1.7 13:42.52 postgres > 2376 postgres 20 0 8508m 531m 527m S 6.0 1.7 13:35.51 postgres > 13195 postgres 20 0 8508m 531m 527m S 5.3 1.7 12:33.65 postgres > 3027 postgres 20 0 8508m 531m 527m R 3.3 1.7 13:29.06 postgres > 2349 postgres 20 0 8508m 530m 526m S 3.0 1.6 13:38.19 postgres > 2358 postgres 20 0 8508m 531m 527m S 3.0 1.7 13:44.59 postgres >26 root 20 0 000 S 0.3 0.0 0:08.64 ksoftirqd/5 > 2335 postgres 20 0 8489m 2732 1340 S 0.3 0.0 1:00.48 postgres > > So, wondering if anyone has any suggestions what the problem is, or how to > fix it? Why is Postgres apparently using only one core, even though it has > many processes? What tools could I use to further diagnose? > > My changed Postgres settings are as follows: > > shared_buffers = 8GB > autovacuum = on > effective_cache_size = 8GB > work_mem = 128MB > maintenance_work_mem = 64MB > wal_buffers = 1MB > checkpoint_segments = 10 > > The server is set up as described here: > http://steveko.wordpress.com/2013/05/08/tilemill-server/ > > I'm not yet using any tile cache. I will do that next, but the problem I'm > trying to solve at the moment is very slow tile generation, not slow > serving of rendered tiles. > > Many thanks in advance, > Steve > > > [1] > http://gis.19327.n5.nabble.com/TileMill-performance-td5751158.html > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > -- 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] Making iD the default editor on osm.org
+1 And don't forget JOSM basic and expert modes... which are already providing an intermediate step between P2/iD dans the full featured JOSM. +1 also to make iD the default editor on osm.org 2013/8/23 Frederik Ramm > Hi, > > > On 08/23/13 01:11, Paul Johnson wrote: > >> > Given the maintenance situation on P2, promoting iD seems like the >> only way forward. >> >> Web launch a JOSM session? >> > > As an avid JOSM user and former member of the JOSM programming team I am > happy to see that JOSM is thriving. > > Making the default "edit" action web-launch JOSM however would probably be > the end of that (and not just because of the technological issues of web > launch). Tons of newbies, overwhelmed by JOSM's broad array of capabilities > and the not-necessarily-simple user interface that comes with it, would > violate our data in ways that would make experienced mappers hark back to > the good old days when it was only Potlatch 1 that people could do damage > with. The limited available JOSM developer time would quickly be used up by > making every bit of JOSM "newbie proof", and experienced users would > complain about limitations introduced to reduce potential damage. > > Frankly I am quite happy that we have, in JOSM, an editor that, while free > for everyone to try out, does target the more demanding users, and can > therefor afford to be a little more demanding itself. An editor where as a > programmer you don't have to think about whether your users know what a way > or a node is and so on. > > > 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<http://lists.openstreetmap.org/listinfo/talk> > -- 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] Making iD the default editor on osm.org
Imagine something we could se as "co-mapping"... - some chat space (with other mappers nearby or using same language) - a way to share the area you're mapping with someone else who could help you 2013/8/21 Pieren > On Wed, Aug 21, 2013 at 1:00 PM, Ben Abelshausen > wrote: > > Sometimes it almost looks like some people here are afraid of new users. > > +1 > We also have to see "deletions" as positive contributions "a priori" > when it is really fixing something (e.g. removing an obsolete POI). > > > A better way of preventing mistakes is to prevent first edits being a > lonely > > experience and to increase interaction with local communities instead of > > making editors more complicated. > > Mapcraft could inspire iD in this way : a 'chat' window is immediatly > available. Having the possibility to talk immediatly with the > community present on irc for instance or an iD chat room would also > help a lot. > > Pieren > > _______ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- 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] Making iD the default editor on osm.org
Maybe a short summary like: "you have added xxx objects, modified yyy object and deleted zzz objects" would help in this dialog ? 2013/8/17 Tom MacWright > iD has always had a clear message to this direction every time any user > saves: > > > "The changes you upload as tmcw <http://www.openstreetmap.org/user/tmcw> > > will > be visible on all maps that use OpenStreetMap data." > > https://cloudup.com/ckQTglHaKYJ > > > On Sat, Aug 17, 2013 at 3:37 PM, Pieren wrote: > >> On Sat, Aug 17, 2013 at 3:45 PM, Martin Raifer wrote: >> >> > What about requiring double clicks on the delete icon >> >> I would prefere a popup window coming only the first time someone use >> it, saying "be carefull, you will really delete something in the real >> database if you save your work" or something like that. >> >> Pieren >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > -- 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] Making iD the default editor on osm.org
Users can already decide in their profile, so we're talking more about a "default by default"... 2013/8/17 Tom MacWright : > Hi, > >> Why do we set a default editor right from the beginning and do not let the >> user decide ? > > That's a question for another thread, but the answer is likely to be > 'reasonable defaults'. > > Tom > > > On Sat, Aug 17, 2013 at 10:34 AM, colliar wrote: >> >> Hey, >> >> >> Why do we set a default editor right from the beginning and do not let >> the user decide ? >> >> I think it depends on the individual which editor fits to whom. I met >> several people who know how to work with GUIs but are not familiar with >> OSM. All had no problem getting along with JOSM right away and some >> where looking for features like "filter", "purge", "export to file/gpx" >> and "printing". >> >> The international student projects on several highschool across Europe >> did only use JOSM and it work, too. >> >> A short description of iD, Potlatch2, JOSM and Merkaartor with links >> would be nice. >> >> Cheers >> Colliar >> >> >> On 16.08.2013 08:59, Frederik Ramm wrote: >> > Hi, >> > >> > it has been proposed to make the newly released iD v1.1 the default >> > editor on openstreetmap.org, meaning that if someone doesn't explicitly >> > chose an editor they will open iD instead of Potlatch. >> > >> > Refer to the previous thread "In the works: iD 1.1" for details on that >> > release. >> > >> > The relevant GitHub "pull request" is here: >> > >> > https://github.com/openstreetmap/openstreetmap-website/pull/453 >> > >> > It is likely that this "pull request" will be "merged" (i.e. accepted >> > and incorporated into the OSM web site) in the near future unless there >> > are important reasons not to. >> > >> > Bye >> > Frederik >> > >> >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- 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] Mapnik style bug in railway=subway
It may be a data problem... The dashed way is the following: http://www.openstreetmap.org/browse/way/207198651 The non dashed one is: http://www.openstreetmap.org/browse/way/207198652 This second way is also part of a relation: http://www.openstreetmap.org/browse/relation/2777287 To me, it looks like this relation is mixing 2 things: - type=route + route=subway - railway = subway The route is fine, but the railway=subway is creating a duplicate with the existing railway=subway that are on the ways themselves. osm2pgsql thus created another "line" object for the whole subway line which makes mapnik draw the dashed subway line twice... making it looking as undashed in some parts. railway=subway should not be on the route relation. 2013/7/16 Maarten Deen : > I'm not sure where to report this, I hope someone here can point me in the > correct direction. > Have a look at the subwaylines here [1] > > The middle one on the right of the marker is dashed, the top and bottom ones > are not. All are tagged with tunnel=yes, the only difference is that the two > that are not dashed have oneway=yes on them. > It appears that oneway=yes on railway=subway does not get it rendered as a > tunnel anymore. I think this should be corrected. > > [1] > <http://www.openstreetmap.org/?mlat=51.92378&mlon=4.467769&zoom=18&layers=M> > > Regards, > Maarten > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk -- 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] Using OpenStreetMap on a daily basis
2013/7/13 : > > Isn't the obvious answer just to provide these services to logged-in > users and if loads of people start creating accounts just to access > free stuff them limit it to actual map contributors. > > It seems crazy to argue that the project cannot provide decent services > to contributors because we would then have to service the entire world. > That just isn't true. > > Kevin > It's not obvious at all, I even think this would have several negative effects: - rewarding contributions one way or another (like giving acces to some additional service) may push quite bad quality contributions (gamification for example is to be considered with a lot of caution) - reducing access over time to services may create a very negative image: imagine you have access to some service, then this access gets limited, usually this is not providing positive feedback - the more services will be on osm.org the less new interesting services will be created on top of OSM data somewhere else. OSM is not a project created to provide services to end users, it is a project to create/share data in order to build services on top of them. The existing slippy map is a limited way to show the tip of our iceberg. It already has some negative effect, with a lot of people not going further and thinking that OSM is just that : an open map of streets... when OSM is much much more. There are plenty of sites providing very interesting services on top of OSM data, and osm.org should allow visitors to discover them instead of replicating more or less these sites and services. -- 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] Using OpenStreetMap on a daily basis
I'm also in favor of such a first page... maybe organized as a splash screen (view/edit/get involved) on top of the existing map. At least it shows that OSM if not only the default map. I would add one more thing "more tools" to link to other maps ans dites based on OSM data providing tools to end users (like mapquest, skobbler, openlinkmap, etc, etc). 2013/7/11 Frederik Ramm : > Hi, > > > On 07/11/2013 11:12 AM, Ian Sergeant wrote: >> >> In my opinion, it was an unfortunate decision taken when >> openstreetmap.org <http://openstreetmap.org> moved from being the wiki >> >> site, to the being our own map rendering. > > > Time for me, again, to bring up this > > http://www.freeworldmap.org/draft-index3.html > > - a design that someone made about 10 years ago or so as a suggestion for a > new OSM front page. It was frequently discussed on the list (google for "osm > three column page" or so) and there were several versions circulating over > the years. > > I don't think anybody is suggesting to use this now, but I'm just writing to > say that there has always been a lot of support for the idea of showcasing > something other than the map. > > > 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 -- 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] Mapnik Lowzoom TIles - proof of concept
I slightly modified the boundary rendering I also added islands and archipelago rendering, which makes seas a bit less empty... Example: http://tile.openstreetmap.fr/?zoom=7&lat=58.13383&lon=-2.9452&layers=B0FFF Work still in progress... and feedback (with permalinks) welcome ! 2013/7/4 Michael Kugelmann : > Am 04.07.2013 11:18, schrieb Christian Quest: >> >> Here is zoom 7 (others are in the render_list queue): > > to me this looks really nice and a huge improvement to the current OSM > default lowzoom rendering! > > > Best regards, > Michael. > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk -- 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] Mapnik Lowzoom TIles - proof of concept
Based on Frederik lowzoom idea, I started improving the low zooms on our OSM-FR style... Here is zoom 7 (others are in the render_list queue): http://tile.openstreetmap.fr/?zoom=7&lat=46.88069&lon=3.13697&layers=B0FFF Here is how I did it: - modify my OSM-FR to remove all labels and boundary at zoom 8 (which was already using landcover/landuse), - generate 4 large PNG using nik2img - combine them and generate one large tiled z8.tif using gdal_translate (133MB, if you want to play with it I can share the result) - create a very simple stylesheet to test using this z8.tif as raster, then add placenames and boundaries It's a work in progress. I'm currently merging this lowzoom stylesheet to my main OSM-FR style sheet. I've not played with imagemagick, it is just a lanczos downscaling made by mapnik. Label ordering is handled by using the place=* tag, then the population=* tag so large cities are placed first. The placename density is limited using text-min-distance. -- 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] Overpass API Public Transport Line Diagram
Isn't the overpass line script only looking at route relations ? There is a relation for this subway, but the operator is STM (not stm)... See: http://www.openstreetmap.org/browse/relation/2996848 and also http://www.openstreetmap.org/browse/relation/270251 Some cleanup may be needed there... 2013/6/27 Guillaume Pratte : > Hello, > > I have discovered tonight the wonders of the Overpass API, and have been > trying to use the Public Transport Line Diagram generator from > http://overpass-api.de/public_transport.html to map the Montreal's subway > lines. > > I have added the required "network" tag on the ways, but the API still > refuses to render thel ine. > > Here's one example, the Orange Line: > > http://www.openstreetmap.org/browse/way/20233474 > > And here is what I think would be the proper way to create the schema for > this line: > > http://overpass-api.de/api/sketch-line?network=stm&ref=2&operator= > > What am I missing? > > Thanks! > > Guillaume Pratte > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- 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
[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] Google Maps being "praised" for removing I-5 colasped bridge quickly
We did some media work around a new highway opening near Lyon. It has been quite well received. We turned it around route calculations as most players had outdated data the route proposed was much longer than using the new highway ;) http://openstreetmap.fr/a89 This page has been visited much more than usually and the referers traced back to several local newspapers and website/blogs. Taking advantage of a bridge collapse is another issue.. I don't feel confortable of doing media work around something like that because it is too much linked with a negative event. Next media work is about Roland Garros international tennis tournament which will start tomorrow outside of Paris... the area never looked as great as on http://u.osmfr.org/m/275/ ;) -- 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] Permalink with marker
2013/5/23 Janko Mihelić : > One solution could be to have a little marker symbol on the lower right of > the map. If the user drags it over the map, it becomes permanent, and when > you click the permalink, it takes it into consideration. That way you could > drag several markers over the map. > > Janko > That's what uMap is made for... http://umap.openstreetmap.fr/ Add markers, polylines, polygons over your choice of base layer + get short link or embeddable HTML Exemple: http://u.osmfr.org/m/4 -- 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 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 : > 2013/5/7 Christian Quest : >> 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 : >> 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
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] Re : Why do we have so many registered users with zero edits ?
The flossmanual is a better beginner guide, I'm sending a link to it in my welcome message to new contributors in France (it has been translated in french) learnosm is another one to consider too... (french translation available too) Kort is a very nice approach. Wheelmap styled apps are also easy to use. In fact, as long as you don't have to deal with topology/geometry, the required level to add more details to existing data is very low and opens contribution to a much broader audience... then you can enter the "editors" world with iD I've also seen several people afraid of "breaking" things, and I thought of some global geometry lock/unlock to allow contributions only at tag level or switch to a tag+geometry level. 2013/4/16 Stefan Keller > Hi Mikel > > Yes, th iD editor is a good step in the right direction. > But even given that this tool is well made and self explanatory there is > still room for better introductory material. > The main entry page [1] for example is not very appealing, little bit > outdated and lacks pictures and video material. > To me it would be worthwile to consider dedicating a (OSMF? GSoC?) project > to this. > > Yours, Stefan > > [1] http://wiki.openstreetmap.org/wiki/Beginners%27_guide > -- Christian Quest - OpenStreetMap France Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/s<http://openstreetmap.fr/sotmfr2013>ynthese-sotmfr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Crossroad names
highway=traffic_signals + name=* are now also visible: http://tile.openstreetmap.fr/?lon=139.71686&lat=35.61534&zoom=18 You'll see that adding names to traffic_lights on complex crossroads causes the same name to be rendered multiple times in some places: http://tile.openstreetmap.fr/?lon=139.71825&lat=35.61857&zoom=18 A better tagging scheme seems necessary as one "thing" should be in the database just once. If we could avoid relations and use either the junction=yes or a place=junction/crossroad (place name are usually meant to be rendered that's why I'm thinking about it). Think also about Nominatim... place=* makes more sense for that purpose. 2013/3/25 Vladimir Vyskocil : > > And there are more than 7000 nodes with highway=traffic_signals and name=* > in Tokyo and its suburbs ! > Another country, another solution for the same tagging "problem". > > Vlad. -- 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] Crossroad names
I wanted to try rendering those crossroad names so I've had a quick look in Korea, near Seoul and found many nodes with names around intersecting highways. Example: http://osm.org/browse/node/414684650 What is the current tagging scheme for crossroad names ? junction=yes ? Is it used in countries where crossroad names are meaningful and worth rendering on a map ? Based on the few data I've looked at, there are nodes with names but not connected to highways and without any tag allowing to say "this looks like a crossroad name that I should render". Rendering anything on a map implies to have a stable tagging scheme, and have available data using these tags. It is also true that as long as something is not rendered on most maps, nobody really care adding that "invisible" information in the database (chicken and egg problem). ! Here is a quick and dirty rendering on the junction=yes + name=* tags that will make visible the 1800+ nodes overpass found mostly in Korea: http://tile.openstreetmap.fr/?zoom=17&lat=37.40505&lon=127.12573 -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Interesting cases of vandalism?
I remember a case where a contributor was removing shop names (or even shop POI) because he did not want OSM to become too much shop oriented... but vandalism is quite unusual. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Openstreetmap server down?
If you need to download data for your edit addiction, you can do so at: http://api.openstreetmap.fr/api/ Upload won't work of course as it usually does (acting as an upload proxy to london server). -- Christian Quest - OpenStreetMap France Week-end "SOTM-FR" à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik at zoom=19
One little step towards zoom 19 : http://tile.openstreetmap.fr:13080/?zoom=19&lat=48.87164&lon=2.30134&layers=0B That's a new, fast server* under test (but hooked to my home DSL line so be patient). * see on wiki: http://wiki.openstreetmap.org/wiki/FR:Servers/Hardware#Dell_R610 2013/2/13 Gervase Markham : > (Sorry I'm late back to this discussion.) > > On 27/01/13 11:39, Richard Fairhurst wrote: >> If you want to make it happen, the best way to do this is to take part in >> the project to port the current stylesheet to Carto: >> https://github.com/gravitystorm/openstreetmap-carto >> >> and to make sure that the resulting stylesheet is actually capable of >> rendering at z19 convincingly. (The current XML one isn't.) > > I'm happy to cheerfully admit that I'm requesting that this happen > without resources to back it up. So I'm not going to get all entitled > :-) If z19 happens, count me as someone cheering you on! If not, no > criticism. > >> Beyond that, it'll take some investigation into what extra hardware burden >> z19 will impose. Perhaps you could help by running some tests into that? > > I'm not sure I have the capability to do that. :-| I'd anticipate a max > of 4x the disk space needed by z18, as others have said, but less if we > are smart about it and e.g. only render certain latitudes, or densely > populated areas, or render on demand. > > Gerv > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France Week-end "SOTM-FR" à Lyon, les 23-24 février prochains: http://openstreetmap.fr/sotmfr2013 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SOTM-FR online registration open
Online registration for the upcoming State Of The Map France are now open on eventbrite: http://sotmfr2013.eventbrite.fr/ It will take place in Lyon on 23rd and 24th of february (that's in 2 weeks). For more details about this event, please have a look at the wiki pages: http://wiki.openstreetmap.org/wiki/FR:SotmFR (french) http://wiki.openstreetmap.org/wiki/SotmFR (english) Do not hesitate to forward this news in you local community, everybody is welcome ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to create very large jpeg from OSM file
Have a look at Bigmap: http://wiki.openstreetmap.org/wiki/Bigmap It allows to collect tiles and make a large image of them. 2013/2/1 Tanveer Singh > I went to the openstreetmap.org site, and the largest jpg I can export is > around 2000x2000 > > I was wondering whether there exists a software where I can give it the > .osm file(downloaded from a service like cloudmade), and then create very > big files like 8000x8000 in size? > -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest<http://openstreetmap.fr/u/christian-quest> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wow, Google Maps now has detailed maps for North Korea!
Hey Google... what about... Sarajevo ? Gaza ? Goré ? ... ;) Sarajevo: http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=18.38325&lat=43.83595&zoom=13 Gaza: http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=34.45762&lat=31.52649&zoom=14 Goré, Tchad (OSM EUROSHA* team mapping): http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=16.63646&lat=7.92523&zoom=16 Bangui, Centrafrique (OSM EUROSHA* team mapping): http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=-16.27426&lat=12.57939&zoom=16 Ziguinchor, Senegal (OSM team at work there): http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=-16.27426&lat=12.57939&zoom=16 * More about EUROSHA: http://eurosha-volunteers-blog.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] piwik.openstreetmap.org - what is it?
My setup is a plain one, no frills, nothing special, just open to every site that wants to take part to this experiment of tracking accross OSM related sites to understand how visitors move between all them and finally register/contribute or not... but for this the main OSM site should also take part to the experiment. Although current tracking is not anonymous (full IP is stored), anonymized data can be queried for studies thru piwik's API. Adding another site is quite simple: - give me the URL of the site, - I'll send you back the HTML code to include in your pages 2013/1/25 Jeff Meyer > Christian - > My apologies! > What would it take to add other sites? What other sites did you have in > mind? I take it www.openstreetmap.org is out of the question, as we're > already running one for that. Or, is yours set up in a way that's more > generic / anonymous than the core piwik? > > - Jeff > > > On Thu, Jan 24, 2013 at 2:08 AM, Christian Quest > wrote: > >> It is also sad not to get any request to add sites to our piwik instance >> at OSM-FR to start gathering global statistics as I offered to do almost 2 >> weeks ago... >> >> >> 2013/1/24 Jan Kučera >> >>> It is sad we are running software whose results no one can see... >>> >>> >>> 2013/1/10 Christian Quest >>> >>>> 2013/1/10 Tom Hughes : >>>> > On 10/01/13 10:56, Christian Quest wrote: >>>> > >>>> >> One single piwik instance, and all sites who wants to participate to >>>> >> the study just embed the same global piwik.js on their site. >>>> >> All analytics are done by this single global piwik db. >>>> >> >>>> >> ... maybe I miss something, but that's a basic feature I expect from >>>> >> piwik: gather data from more than one single site. >>>> > >>>> > >>>> > Somebody has to manage adding them all, and allocating site ID values >>>> for >>>> > them and keeping those up to date as sites come and go. >>>> > >>>> > Not to mention that if sites want to use things like goals and custom >>>> > variables then those also have to be configured by somebody. >>>> > >>>> > All of which is before we even think about questions of hardware >>>> scaling for >>>> > such an endeavour. >>>> > >>>> >>>> >>>> Ok... where's the problem ? No hardware to deal with that ? >>>> >>>> We (OSM-FR) have some and the admins to take of it... and if it looks >>>> useful to collect these global data, why not try to setup something ? >>>> >>>> >>>> -- >>>> Christian Quest - OpenStreetMap France - >>>> http://openstreetmap.fr/u/cquest >>>> >>>> ___ >>>> talk mailing list >>>> talk@openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk >>>> >>> >>> >>> ___ >>> talk mailing list >>> talk@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk >>> >>> >> >> >> -- >> Christian Quest - OpenStreetMap France - >> http://openstreetmap.fr/u/cquest<http://openstreetmap.fr/u/christian-quest> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> >> > > > -- > Jeff Meyer > Global World History Atlas > www.gwhat.org > j...@gwhat.org > 206-676-2347 > <http://www.openstreetmap.org/user/jeffmeyer> osm: Historical > OSM<http://wiki.openstreetmap.org/wiki/Historical_OSM> > / my OSM user page <http://www.openstreetmap.org/user/jeffmeyer> > t: @GWHAThistory <https://twitter.com/GWHAThistory> > f: GWHAThistory <https://www.facebook.com/GWHAThistory> > > > > -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest<http://openstreetmap.fr/u/christian-quest> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] piwik.openstreetmap.org - what is it?
It is also sad not to get any request to add sites to our piwik instance at OSM-FR to start gathering global statistics as I offered to do almost 2 weeks ago... 2013/1/24 Jan Kučera > It is sad we are running software whose results no one can see... > > > 2013/1/10 Christian Quest > >> 2013/1/10 Tom Hughes : >> > On 10/01/13 10:56, Christian Quest wrote: >> > >> >> One single piwik instance, and all sites who wants to participate to >> >> the study just embed the same global piwik.js on their site. >> >> All analytics are done by this single global piwik db. >> >> >> >> ... maybe I miss something, but that's a basic feature I expect from >> >> piwik: gather data from more than one single site. >> > >> > >> > Somebody has to manage adding them all, and allocating site ID values >> for >> > them and keeping those up to date as sites come and go. >> > >> > Not to mention that if sites want to use things like goals and custom >> > variables then those also have to be configured by somebody. >> > >> > All of which is before we even think about questions of hardware >> scaling for >> > such an endeavour. >> > >> >> >> Ok... where's the problem ? No hardware to deal with that ? >> >> We (OSM-FR) have some and the admins to take of it... and if it looks >> useful to collect these global data, why not try to setup something ? >> >> >> -- >> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest >> >> _______ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest<http://openstreetmap.fr/u/christian-quest> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] POI display on osm.org
Some good ideas can be found on http://openlinkmap.org/ But of course it depends on the goal of such a new feature... bring something useful mainly for contributors or for a more broader audience. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
