[talk-ph] Fwd: RE: [CrisisMappers] Fwd: Super Typhoon Haiyan: Help Map Storm Damage
Forwarding links to more imagery by CNES, distributed by Astrium, and hosted by ESRI. Thousands (literally !) thanks to all, and also for the revolution that this public license Charter Pleiades represents ! For once, I do hope that big ears are listening... Jean-Guilhem Message original Sujet: RE: [CrisisMappers] Fwd: Super Typhoon Haiyan: Help Map Storm Damage Date : Fri, 15 Nov 2013 18:42:28 + De :Ryan Lanclos rlanc...@esri.com Répondre à :crisismapp...@googlegroups.com Pour : crisismapp...@googlegroups.com crisismapp...@googlegroups.com Copie à : ver...@un.org ver...@un.org, aguil...@un.org aguil...@un.org, d...@geekli.st d...@geekli.st, Sara-Jayne Terp sara.far...@btinternet.com Hello all -- just an update to the imagery email from yesterday I sent. We've made 2 scenes available for public use, including the OSM community, etc thanks to Astrium. Here are a few links to help you get started: Web services for inclusion into your maps and apps: http://disasterresponse.maps.arcgis.com/home/item.html?id=8e2d1255f8234af6b9dce3672f7b3402 Web map with the imagery included: http://disasterresponse.maps.arcgis.com/home/webmap/viewer.html?webmap=8e2d1255f8234af6b9dce3672f7b3402 Swipe map application of before and after imagery, GIS data resources and other maps for damage, etc are here: http://www.esri.com/services/disaster-response/hurricanes/typhoon-hayian-yolanda-maps Please let us know if the Esri Disaster Response Program can help in any way! Look forward to seeing you all in Nairobi next week. Safe travels! Ryan * * *Ryan Lanclos | Emergency Management Humanitarian Industry Manager | Esri* T +1 909-793-2853, ext. 1885 | M +1 909-289-1583 ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Scientific American - What Happens to Google Maps When Tectonic Plates Move?
Link: http://blogs.scientificamerican.com/critical-opalescence/2013/11/11/what-happens-to-google-maps-when-tectonic-plates-move/ This is a nice readable article on the accuracy of GPS coordinates and georeference satellite imagery, geodetic datums, and how geographers try to keep up with Earth's dynamic crust. An interesting link in the article is this animation of a GPS network in Japan that shows the propagation of ground waves in the minutes after the 2011 Japan earthquake: http://www.youtube.com/watch?v=rMhhyb6Yy94 ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Typhoon Haiyan Mapping Progress
Hi, On the hotosm tasks I participated in (342 and 347 mainly), I noticed many tiles marked as finished and even validated, when several buildings and sometimes whole areas have not been traced yet. What could be done to avoid this ? * I think a clearer Unlock it!. button might help for those who want to stop and only see the Mark Task as Done button. * For new tasks, the introduction and workflow could maybe add a note to only click Done if you are 100% sure ALL has been traced. * It seems impossible to invalidate a tile that is already validated. Another solution could be to restart a new task for the same area once the initial one is validated to check for missed parts. Task 360 kind of does this, but mixes adding lacking buildings and evaluating damage. This seems logical, but the result is that some mark a task as done just after adding the buildings, and some omly after assessing the damage (without adding new buildings). I'm not complaining ! It is really great to see so many persons involved, and I'm sure it is very helpful. The problems mentionned above are really small compared to the benefits. Happy mapping, and thanks to all. Totor ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] POI Address problem
Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.com wrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview again, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.comwrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overviewagain, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] POI Address problem
Here are a few applications which suffer from repeating the same information millions of times: PostGIS wget the bandwith of my internet provider for downloading all that cruft scripts to unpack and read those exorbitantly long XML files, even when I'm not working with those addresses, so I'm unpacking and processing them in vain over and over again. Even with 8G of memory I can't seem to hand JOSM more than about 1G to work with. Every time autosave kicks in, I'm waiting. I'll be waiting even longer when those xml files grow even larger. And technology improvements like SSDs only help so much. Applications on mobile platforms (the ones Ivo is talking about) would also benefit from a sensible approach. All that processing drains the battery even faster and memory for those devices are at premium prices. So it would make a lot more sense for those apps to be improved, than for us to start millioniplicating data. Jo 2013/11/15 Ivo De Broeck ivo.debro...@gmail.com I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.com wrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013 at 10:50 AM, Marc Gemis marc.ge...@gmail.comwrote: I'm reading http://wiki.openstreetmap.org/wiki/Nominatim/Development_overviewagain, especially the section on Building indexing Buildings, houses and other lower than street level features (i.e., bus stops, phone boxes, etc.) are indexed by relating them to their most appropriate nearby street. The street is calculated as: 1. The street member of an associatedStreet relation 2. If the node is part of a way: 2.1 If this way is street level, than that street 2.2 The street member of an associatedStreet relation that this way is in 2.3 A street way with 50/100 meters and parallel with the way we are in 3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of 4. The nearest street (up to 3 miles) 5. Not linked It seems that it takes one of the streets from the associatedStreet relation to work with. The segment should be long enough (longer than 50-100 m ?). It then works with this street. It simply ignores the tags on the associatedStreet. This would make the relation useless to solve any issue regarding name and postcode for streets that are the border between 2 villages. The 2 names in the standard tag are required, otherwise many QA-tools will complain name:left/right is not recognized, or are they ? (yeah I know do not tag for ... :-) ) You can't use a semi-colon in the name (to indicate multiple names) otherwise another bunch of QA-tools complain that there are 2 names on a highway. BTW, the postcode is also wrong in my example. It should be 2840. It has time, Glenn, it's wrong for several weeks now, so a day more or less does not matter. m On Thu, Nov 14, 2013 at 10:26 AM, Ben Abelshausen ben.abelshau...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:20 AM, Glenn Plas gl...@byte-consult.bewrote: If it can wait I'll check this evening with full attention. That's up to marc. But I guess he would like to see his work be made into something useful. :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list
Re: [OSM-talk-be] POI Address problem
I didn't say that we have to repeat the addr:postcode, or addr:province, etc. That's not taken from the node/building anyway. There we really need an area representing the postcode. So repeating the address field or keeping a reference to another table does make a huge difference, a varchar(1024) or a pointer of 64 bits ? Where the latter saves you a join to find the streetname. You'll need the streetname field anyway, since not everybody is using associatedStreets. And don't forget our Belgian compromise to place the name on the street, the relation and the node/building. Did you see http://www.openstreetmap.org/user/Pieren/diary/20385 ? More or less the same conclusions., associatedStreets aren't accepted. The associatedStreet relation is the best solution from a database design point, but with the current mappers (non-dba's) and the set of tools we have (both editors and consumers), it seems more like a useless vehicle that's difficult to explain and maintain. And BTW, I can say the same for repeating the name of the city on each busstop, a waste of diskspace :-) Maybe we should more focus on getting the city and postal code boundaries into OSM, so we do not have to repeat that data on the lower level features (not on the relations, nor on the nodes). When the data can be found by the position of a node, there is no need to repeat it. When we can start the import of AGiV/Crab it might be easy to have the relations and the necessary information on the nodes, but right now, with the current set of tools of JOSM, it's hard to keep it correct. I don't know for other editors. Furthermore in JOSM you can't add POI's and buildings with the same house number without warnings. This might scare people as well. A lot people that add information for the first time, add an address in iD, without associatedStreet. So during the import, a poor soul might figure out how to merge that data with the imported data and update the associatedStreet in the correct way. I'm thinking how I can describe this so less experienced mappers than you and me understand what they should do. Anyway, off my soapbox. For you poor machine, which options to you give to JOSM at startup time? Do you use -Xmx (max heap size) ? Do you use a 64-bit java VM ? m On Fri, Nov 15, 2013 at 12:38 PM, Jo winfi...@gmail.com wrote: Here are a few applications which suffer from repeating the same information millions of times: PostGIS wget the bandwith of my internet provider for downloading all that cruft scripts to unpack and read those exorbitantly long XML files, even when I'm not working with those addresses, so I'm unpacking and processing them in vain over and over again. Even with 8G of memory I can't seem to hand JOSM more than about 1G to work with. Every time autosave kicks in, I'm waiting. I'll be waiting even longer when those xml files grow even larger. And technology improvements like SSDs only help so much. Applications on mobile platforms (the ones Ivo is talking about) would also benefit from a sensible approach. All that processing drains the battery even faster and memory for those devices are at premium prices. So it would make a lot more sense for those apps to be improved, than for us to start millioniplicating data. Jo 2013/11/15 Ivo De Broeck ivo.debro...@gmail.com I agree with that, address:street is easily to change or view at all apps for smartphones or tablets too. 2013/11/15 Marc Gemis marc.ge...@gmail.com Got this answer from lonvia on help.osm.org You've mapped it correctly, Nominatim is just not very good at updating associatedStreet relations. It's a known bughttps://trac.openstreetmap.org/ticket/4619 . Here is what happened: you've originally put the house into this associatedStreet relationhttp://www.openstreetmap.org/browse/relation/2594673 which does contain the 'Pierstraat - Matenstraat' street. Nominatim simply uses the first street it finds in such a relation for the name an ignores all tags on the relation itself, so that is where the name comes from. Later you have moved the house to the new relation and that move was not caught by Nominatim's update process. The houses will only be updated when they are changed themselves again. also interesting is this quote from lonvia in the above mentioned bug: Nominatim would be perfectly happy if you added only addr:street tags and got rid of the associatedStreet relations. The relations mostly don't carry any additional information and are a bit of a pain to handle. addr:street is much better supported. So I wonder more and more whether we should add those theoretically nice associatedStreet relations On Thu, Nov 14, 2013 at 1:10 PM, Marc Gemis marc.ge...@gmail.comwrote: the help thread is here: https://help.openstreetmap.org/questions/28075/how-to-correctly-map-a-pois-address seems that Nominatim was not updated after the associatedStreet-relation update On Thu, Nov 14, 2013
[OSM-talk-be] My Mapproxy Web page (was: WMS for OSM using EPSG:31370)
On 2013-11-15 22:03, André Pirard wrote : Anyway, I decided to stop speaking of Mapproxy repeatedly and to write a Web page instead. I hope to finish it tonight and it will contain a super simple procedure with a guaranteed-to-work simple configuration for OSM (I have doubts about the config in the OSM wiki page). There you are (meaning here it is) http://www.papou.byethost9.com/maps/mapproxy/. But there's a hitch. If I display Mapproxy's Lambert72 on JOSM, there's a nasty offset with OSM data (which JOSM reprojects 4326 - Lambert72). That should be due to a difference between the proj4 definitions in Ubuntu (used by Mapproxy) and in JOSM. If I use Lambert08, it's correct. Most probably a JOSM bug again: I've had to upgrade it because Lambert was no longer working in the first place. I will investigate. Tell me if you meet that problem, if it's annoying for you and it you find which is the culprit. Any feedback appreciated, especially what would be missing for the first steps while still keeping it simple. All this said, I find it very strange from AGIV, as well as SPW, to work exclusively in 31370, because all servers in the world serve 4326, maybe in addition to a local EPSG, and BTW, if you want the Mapproxy documentation in any other language, switch my page to that language and then click the Mappproxy link. Who did you call Polyglot? ;-) BTW2, I was surprised that the Dutch translation looks better to me than the French one. I expected exactly the opposite. But, of course, I'm more demanding in French. I read Introductie and my amazement abruptly turned to laughter with the last two words:Mapproxy terrein :-) Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Upcoming changes to OpenStreetMap.org website
Hi, I would like to support this feedback because my impression is very similar: On 13.11.2013 11:58, Peter Barth wrote: * When I move and zoom the map I occasionally get a Loading...-text in the textbox, which makes the Welcome...-text bounce up and down. This is annoying. * The color/design of login/signup-buttons is too light so that it looks like they're deactivated. I'd like to have them darker. * Imho there should be a way to remove the Welcome-textbox, too. (Didn't check if it vanishes for registered users) I would especially like to point out that mappers using offline editors are often not logged into osm.org and that I do not assume that non-editing users should create accounts. Nevertheless, many thanks the developers for the effort they have put into our project's website! Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] M31 at Holbrook
On 15/11/2013, at 11:14 AM, Arthur Geeson wrote: Hi, Yesterday I drove down the M31 and left the GPS running and this morning I uploaded the gpx 'Parramatta to Lancefield'. I get extremely good correlation all the way with the exception of the new Holbrook by-pass. I was wondering if we should get some local confirmation before making the changes to the map as some other local streets are affected? Thanks Arthur (geesona) It so happens that I did some traces of the bypass almost 2 weeks ago (at the start of my holidays) including ramps, and will be going back through Holbrook tomorrow morning (on the way home from holidays) to get details of some of the other local street closures. (I was going to stay in Holbrook tonight, but only got as far as Albury before I decided to stop for the night.) I had originally added the bypass as highway=construction, source=extrapolation (or something similar), once the bypass was opened no-one bothered to check the route when it was changed to highway=motorway - including adding non-existent bridges over roads (they have either been closed, or the road actually doesn't cross it). I was also going to ask about the route numbers for the Hume Hwy/Freeway. In NSW it is M31 all the way (the older A31 signs between Albury and Gundagai have been replaced by M31.) In Victoria, most of the signs have M31 in the National Highway shield, but some newer signs have just M31 (no shield). Some newer signs on M39 have also had the shield removed. Is it safe to remove the network=NH tags from these routes? Mark P. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Geoscience NATMAP 250K Topo Maps
From: Andrew Harvey [mailto:andrew.harv...@gmail.com] Subject: Re: [talk-au] Geoscience NATMAP 250K Topo Maps We'd have to get confirmation that data source was happy with attribution in accordance with ODbL sections 4.2 and 4.3 which are keep intact any copyright or Database Right notices or a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from the [the datasource] That is a pity. The fact that OSM can't accept CC BY licensed works is reminding me why I stopped contributing to OSM many months ago... If taken literally CC BY's attribution requirements are very onerous. Creative Commons themselves appears to recognize this and the 4.0 drafts have much more reasonable attribution language, more in line with the ODbL. Even under CC BY-SA there were some data providers who felt that the conventional attribution methods for web maps were insufficient and we still couldn't use CC BY data without confirmation. I believe when CC 4.0 comes out its attribution will be compatible with ODC attribution, so we'll finally stop having to deal with the CC attribution flaws. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Geoscience NATMAP 250K Topo Maps
On Fri, 2013-11-15 at 18:30 +1100, Andrew Harvey wrote: but I don't see the benifit in hosting them when GA already do a pretty good job at this. If your application doesn't support z/y/x then patch it, and if you can't it would be much simpler to just proxy the GA tile server to give a z/x/y endpoint. In the case of FoxtrotGPS, I'll prepopulate its cache with the GA files, transforming from z/y/x to z/x/y in the process. FoxtrotGPS always checks it's cache before looking to download. Not hard. FoxtrotGPS only looks for .png files but if it finds JPEG files with a .png extension, its quite happy :-) David ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] M31 at Holbrook
Hi Arthur, mark, About four weeks ago I went down to Melbourne, for a bike ride and did have my GPS on through Holbrook. I saw someone had put the bypass in so I didn't think to check it. I've just uploaded my GPS and it matches the other one very well and is substantially different to the construction ways. Last Year I wen down to Nagambie lakes ( for a bike ride) and surveyed most of Holbrook (pre bypass) on the way back. A lot of this is now wrong, because of the bypass. Mark, I'll be going back down to Nagambie Lakes for the same ride this year (in two weeks), so If you run out of time or miss any roads, I will be able to finish them off. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[OSM-talk-ie] Fwd: [Walkers Association of Ireland newsletter] This Day Next Week!
Hi there, forwarding this to ye OSMers in case you are interested. The expected audience is hillwalkers, but it sounds interesting to others too. I'll be in France on that day, otherwise I would have been tempted. -- Forwarded message -- From: Tyndall Mountain Club tyndallmtc...@gmail.com Date: 15 November 2013 16:27 Subject: Fwd: [Walkers Association of Ireland newsletter] This Day Next Week! To: -- Forwarded message -- From: Walkers Association of Ireland websitecont...@walkersassociation.ie Date: 14 November 2013 23:45 Subject: [Walkers Association of Ireland newsletter] This Day Next Week! To: tyndallmtc...@gmail.com This Day Next Week! *WAI Winter Talks Series 2013 / 2014* *THIS DAY NEXT WEEK! * *Wednesday 20th November 2013, 8pm to about 9:30.* *A talk about the Original Survey and Modern Mapping Methods will be given by Dominic Cronin.* http://www.walkersassociation.ie/node/37073 The systematic mapping of Ireland started with the Ordnance Survey from 1829 onwards. To create a map for which all pieces fitted together it was first necessary to measure the earth. The Victorian way of doing this was to measure one length accurately for a baseline and then measure angles to the ends of this to mountaintops and further mountaintops. From this primary triangulation further work led to measuring fields, houses, roads and all other features. At the end of the process there was the creation of the 25 and 6 inch to the mile maps. In contrast modern mapping uses a variety of techniques some based on airphotography, GPS and Electronic Distance Measurement. . . . . The below photo is of a three foot wide theodolite, weighing some 200 pounds, which was lugged to the top of each of the mountains of the primary triangulation! http://www.walkersassociation.ie/node/37082 Following the talk there will be QA and an opportunity to meet others. Venue for Talks : The Lansdowne Hotel (Held in The Raglan Room, downstairs behind The Den Bar) 27-29 Pembroke Road, Ballsbridge, Dn 4 More details including directions at: THE LANSDOWNE HOTEL http://www.lansdownehotel.ie/ . . . With bar facilities at hand and excellent food available from the bar . . . a great evening is promised for all! ALL ARE WELCOME . . . . ! ! ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *Future Events !!!* *Wayfarers / WAI Annual Pub Quiz!* *29th January 2014 - Venue : The Teacher's Club, Parnell Square, Dublin 1* *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *MountainViews / WAI Annual Gala Evening!* *21st February 2014 - Venue : The Lansdowne Hotel, Dublin 4* *. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * *WAI Photography Workshop : May 2014!* *WAI GPS Course : May 2014!* *. . . . and of course further entertaining Spring Talks!* Full Details to Follow. ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Am 15. November 2013 03:24 schrieb Stephan Knauss o...@stephans-server.de: Für OSM müssen die Daten unter den Bedingungen der Contributor Terms freigegeben werden. Da steht dann auch zum Beispiel drin dass wir die Daten in der Zukunft auch unter einen anderen Lizenz veröffentlichen können wenn die Mehrheit dafür ist. Wobei das nicht so ganz klar ist, ob das überhaupt gehen kann, oder? Wenn man davon ausgeht, dass der virale Aspekt der Lizenz funktioniert, und weiterhin, dass alle Daten, die nicht in komplett leerer Umgebung erstellt wurden oder von externen Quellen importiert wurden, auch von ODbL Daten abgeleitet sind, dann haben die Mapper gar nicht mehr das Recht an ihren Daten, sondern diese sind von vornherein und ausschließlich ODbL (sozusagen von der Umgebung und dem Bestand in OSM abgefärbt), und dann geht auch sowas wie ich erkläre alle meine Edits zu PD gar nicht. Mein Bezug sind die hier geäußerten Überlegungen: http://www.openstreetmap.org/user/JimmyRocks/diary/20357 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Stephan Knauss schrieb: Für OSM müssen die Daten unter den Bedingungen der Contributor Terms freigegeben werden. Stimmt! Die Vergesse ich jedes Mal :( Der Rest bleibt aber bestehen: Entweder die Daten dürfen verwendet werden, oder nicht. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-11-15T11:34:10+0100 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Hi, Stephan Knauss schrieb: Konkret: Daten die unter ODbL lizensiert sind sind eben NICHT mit OSM kompatibel. nur zur Beruhigung: Die Daten (zumindest für Passau) sind zur Verbesserung und Vervollständigung der OSM-Datenbank freigegeben und nicht auf ODbL beschränkt. Gruß, Peda -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Mapper helfen in der Katastrophe, schnell und unkompliziert - mal wieder - dafür Danke!
http://geoobserver.wordpress.com/2013/11/15/die-spur-des-bosen-philippinen-katastrophe-teil-2/ mikeE. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Am 15.11.2013 11:32, schrieb Martin Koppenhoefer: A und dann geht auch sowas wie ich erkläre alle meine Edits zu PD gar nicht. Mein Bezug sind die hier geäußerten Überlegungen: Also, erstmal gibt es in Deutschland PD nicht. Aber tun wa mal so als ob das ginge! es ginge, wenn ich die hoch lade, mit dem Zusatz als Willenserklärung. Wenn die auf dem Server sind ist das nicht mehr möglich, weil die schon unter einem anderen Recht stehen. Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Am 15. November 2013 14:45 schrieb Steffen Heinz eifelhu...@gmx.de: Also, erstmal gibt es in Deutschland PD nicht. man kann allerdings alle Rechte freigeben (z.B. cc0) Aber tun wa mal so als ob das ginge! es ginge, wenn ich die hoch lade, mit dem Zusatz als Willenserklärung. geht eben ggf. nicht, darum ging es ja, weil Du die Daten, die Du hochlädst, mit Hilfe der anderen Daten (die schon da waren, und unter ODbL stehen) erstellt hast. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Alexander Lehner schrieb: Hinweise auf bereits existierendes PR Material in diese Richtung werden also dankend angenommen! Falls du den Link auf der Press_Kit-Wikiseite übersehen haben solltest, hier nochmal explizit der OSM-Pressespiegel: http://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
Hallo Martin, Martin Koppenhoefer writes: Am 15. November 2013 03:24 schrieb Stephan Knauss o...@stephans-server.de: Für OSM müssen die Daten unter den Bedingungen der Contributor Terms freigegeben werden. Wobei das nicht so ganz klar ist, ob das überhaupt gehen kann, oder? Wenn man davon ausgeht, dass der virale Aspekt der Lizenz funktioniert, und weiterhin, dass alle Daten, die nicht in komplett leerer Umgebung erstellt wurden oder von externen Quellen importiert wurden, auch von ODbL Daten abgeleitet sind, dann haben die Mapper gar nicht mehr das Recht an ihren Daten, sondern diese sind von vornherein und ausschließlich ODbL (sozusagen von der Umgebung und dem Bestand in OSM abgefärbt), Ist das wirklich so? Wäre bestimmt mal eine interessante Frage für die Legal-Mailingliste oder eine Working group. Ich war bislang der Meinung, dass unsere Datenbank eben gerade nicht unter der ODbL steht. Die Daten gehören der Foundation, mit den Contributor Terms übertragen wir sie. Dadurch sind die abgeleiteten Daten auch nicht von ODbL sondern von anderen Daten abgeleitet für die die CT gelten. Anders wäre es doch auch garnicht möglich dass wir die Lizenz wechseln. Das was später unter der ODbL steht ist der Export der Daten, zum Beispiel als Planet file. Dadurch können auch Andere die Daten frei (unter den ODbL Bedingungen) nutzen. Einen Rückfluss von Änderungen zu OSM erlaubt das aber eben noch nicht, da sehen uns unsere eigenen CT im Weg. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitungsartikel - PR Material - Hausnummern
On Fri, 15 Nov 2013, Peter Barth wrote: Hi, Stephan Knauss schrieb: Konkret: Daten die unter ODbL lizensiert sind sind eben NICHT mit OSM kompatibel. nur zur Beruhigung: Die Daten (zumindest für Passau) sind zur Verbesserung und Vervollständigung der OSM-Datenbank freigegeben und nicht auf ODbL beschränkt. Und wir haben die Landshuter Daten erhalten, nachdem sich das Vermessungsamt Landshut auf dem bayerischen Staedtetag mit dem aus Passau getroffen hat, um genau dieses Thema zu besprechen. A.___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] che futuro
E' uscito un mio articolo su che futuro! http://www.chefuturo.it/author/simonecortesi/ Parla di osm+filippine -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Restyling openstreetmap.org imminente
che ci piaccia o no, bisogna avere anche un approccio di marketing, wikipedia ha successo perché poi quando io scrivo la voce sul calciatore so che poi le mie parole verranno lette da milioni di persone, su OSM io taggo il mio bellissimo ristorante, ci metto il sito internet, gli orari d'apertura, il tipo di cucina e poi dico se fa cucina biologica e se c'è la sala fumatori, clicco su salva e vedo (se zoommo correttamente) una forchetta e un cucchiaio, l'utente medio dice: bah chi me lo fa fare? Ritorno su wikipedia... +42 Marketing è la parola chiave! A proposito di wikipedia, su GEarth c'è la possibilità di attivare i POI di wikipedia, noi stiamo collaborando pesantemente e manco si vedono. W il marketing!!! ; ) Ciao G ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] su CheFuturo: simone cortesi che parla di OSM e Filippine
http://www.chefuturo.it/2013/11/cosi-noi-hacker-stiamo-aiutando-i-soccorritori-delle-filippine/ -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT, ma anche nOT] Dati aperti
Oltre a quello che ha elencato Martin, anche l'infrastruttura ciclabile (piste e corsie, rastrelli) 2013/11/14 Martin Koppenhoefer dieterdre...@gmail.com 2013/11/14 Michael Moroni michael.mor...@mailoo.org ) Che tipo di dati servono per OpenStreetMap, da essere poi importati in maniera automatica o manuale? se hanno un elenco delle strade e civici, ben venga, se invece i civici hanno delle coordinate, ancora meglio ;-) Poi dipende, se hanno delle ortofoto migliori o più recenti delle solite, anche questi possono essere molto utili, poi qualsiasi dato georiferenziato è utile, nonchè elenchi di parchi, elenchi di uffici pubblici, lampadari stradali, limiti di velocità, ... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] che futuro
Bell'articolo, a parte il titolo che è fuorviante. Scritto così sembrerebbe che soltanto gli hackers siano in grado di contribuire, nella realtà le modifiche sono molto semplici, alla portata di chiunque. Ciao /niubii/ Il giorno 15 novembre 2013 09:36, Simone Cortesi sim...@cortesi.com ha scritto: E' uscito un mio articolo su che futuro! http://www.chefuturo.it/author/simonecortesi/ Parla di osm+filippine -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] che futuro
chefuturo è una redazione, e proprio per questo usa le stesse dinamiche. Pertanto i titoli sono scelti dalla redazione. Ad esempio in questo mio articolo http://www.chefuturo.it/2012/10/perche-apple-ha-sbagliato-strada-con-le-sue-mappe-per-ios6/ hanno messo il titolo Perché Apple ha sbagliato strada con le sue mappe per iOS6 ... dove in realta parlo di osm... 2013/11/15 Francesco Pelullo f.pelu...@gmail.com: Bell'articolo, a parte il titolo che è fuorviante. Scritto così sembrerebbe che soltanto gli hackers siano in grado di contribuire, nella realtà le modifiche sono molto semplici, alla portata di chiunque. Ciao /niubii/ Il giorno 15 novembre 2013 09:36, Simone Cortesi sim...@cortesi.com ha scritto: E' uscito un mio articolo su che futuro! http://www.chefuturo.it/author/simonecortesi/ Parla di osm+filippine -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] che futuro
L'avevo immaginato. In ogni caso, complimenti per l'articolo. Ciao /niubii/ Il 15/nov/2013 11:07 Maurizio Napolitano napoo...@gmail.com ha scritto: chefuturo è una redazione, e proprio per questo usa le stesse dinamiche. Pertanto i titoli sono scelti dalla redazione. Ad esempio in questo mio articolo http://www.chefuturo.it/2012/10/perche-apple-ha-sbagliato-strada-con-le-sue-mappe-per-ios6/ hanno messo il titolo Perché Apple ha sbagliato strada con le sue mappe per iOS6 ... dove in realta parlo di osm... 2013/11/15 Francesco Pelullo f.pelu...@gmail.com: Bell'articolo, a parte il titolo che è fuorviante. Scritto così sembrerebbe che soltanto gli hackers siano in grado di contribuire, nella realtà le modifiche sono molto semplici, alla portata di chiunque. Ciao /niubii/ Il giorno 15 novembre 2013 09:36, Simone Cortesi sim...@cortesi.com ha scritto: E' uscito un mio articolo su che futuro! http://www.chefuturo.it/author/simonecortesi/ Parla di osm+filippine -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] che futuro
Grande Simone :) Speriamo che qualcun'altro si svegli :) 2013/11/15 Francesco Pelullo f.pelu...@gmail.com: L'avevo immaginato. In ogni caso, complimenti per l'articolo. Ciao /niubii/ Il 15/nov/2013 11:07 Maurizio Napolitano napoo...@gmail.com ha scritto: chefuturo è una redazione, e proprio per questo usa le stesse dinamiche. Pertanto i titoli sono scelti dalla redazione. Ad esempio in questo mio articolo http://www.chefuturo.it/2012/10/perche-apple-ha-sbagliato-strada-con-le-sue-mappe-per-ios6/ hanno messo il titolo Perché Apple ha sbagliato strada con le sue mappe per iOS6 ... dove in realta parlo di osm... 2013/11/15 Francesco Pelullo f.pelu...@gmail.com: Bell'articolo, a parte il titolo che è fuorviante. Scritto così sembrerebbe che soltanto gli hackers siano in grado di contribuire, nella realtà le modifiche sono molto semplici, alla portata di chiunque. Ciao /niubii/ Il giorno 15 novembre 2013 09:36, Simone Cortesi sim...@cortesi.com ha scritto: E' uscito un mio articolo su che futuro! http://www.chefuturo.it/author/simonecortesi/ Parla di osm+filippine -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Proposta di roadmap per il capitolo italiano OpenStreetMap Foundation
mi sono iscritto anch'io ;) -- Stefano Fraccaro Web: http://www.stefanofraccaro.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Restyling openstreetmap.org imminente
Risposta generalizzata: In any case it's irrelevant to this PR which is about redesigning what we have, not about adding new features. (cit) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] Matera finalista
Concordo con te ma per me è importante che Matera abbia inserito in nella sua strategia -- Maurizio 'napo' Napolitano http://de.straba.us Il giorno 15/nov/2013 19:57, Simone Cortesi sim...@cortesi.com ha scritto: 2013/11/15 Maurizio Napolitano napoo...@gmail.com: Qui le slide presentate ad Asita http://www.slideshare.net/napo/openstreetmap-quando-gli-smartcitizen-organizzano-le-smartcity Non so quanto del nostro ci sia nel buon procedere della candidatura di Matera. Una cosa che ho però capito è che esiste una bella comunità a Matera e che questa si sta integrando alla meglio con la nostra comunità nazionale. E di questo non posso che essere contento. Non vedo l'ora di essere con tutti voi e con tutti i materani ad OSMIT14. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Area Pic-Nic
...forse paranoia ma se c'è soltanto 1 tavolo + panche in legno ai 2 lati e *nient'altro* posso lo stesso definirla tourism=picnic_site o in questo caso meglio leisure=picnic_table? -- View this message in context: http://gis.19327.n5.nabble.com/Area-Pic-Nic-tp5785346p5785627.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Questa cosa fa impazzire il mio Garmin
Oggi passando di qua: http://www.openstreetmap.org/#map=18/45.34946/9.30895 ho dovuto impostare la mappa proprietaria perché da questo punto il dispositivo non ce la fa a capire nulla. Non so se è corretto mappare così un casello o se occorre fare qualcosa a livello di render con mkgmap, ma se impostate un percorso che passa di qua, col Garmin non arrivate da nessuna parte. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Area Pic-Nic
Am 16/nov/2013 um 00:00 schrieb demon.box e.rossin...@alice.it: ...forse paranoia ma se c'è soltanto 1 tavolo + panche in legno ai 2 lati e *nient'altro* posso lo stesso definirla tourism=picnic_site o in questo caso meglio leisure=picnic_table? sta nel tuo potere di deciderlo :-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] Compartir información, tema de vida o muerte
Columna en el Espectador de Carolina Botero, donde resalta la importancia de los mapas libres en la atención humanitaria y nombra nuestro trabajo en Colombia. http://www.elespectador.com/opinion/compartir-informacion-tema-de-vida-o-muerte-columna-458419 -- Carolina Fundación Karisma http://www.karisma.org.co/carobotero @carobotero -- #=# |___|__\___ | _ | |_ |} (_)(_) Twitter: @fredy_rivera Land Line: +57 8 2691389 Phone USA: (347) 688-4473 Mobil telephone: +57 3108206814 ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
[Talk-es] Programa de Talleres, SIG Libre Girona, Marzo 2014
Saludos, Acabamos de publicar en el sitio web, el programa de Talleres[1] de las 8as Jornadas de SIG Libre de Girona. Muchas gracias a todos aquellos y aquellas que presentaron propuestas de taller. En los próximos días, activaremos también el formulario de inscripción del evento. Estad atentos! Aprovechamos para recordar una vez más, que la convocatoria de recepción de resúmenes (400 palabras máx.)[2], expira el próximo 28/11/2013. No te quedes en casa y muestra todo lo que sabes hacer, en Girona! [1] http://www.sigte.udg.edu/jornadassiglibre/programa/talleres [2] http://www.sigte.udg.edu/jornadassiglibre/comunicaciones Saludos, -- Lluís Vicens Comité Organizador Local Jornadas de SIG Libre Sitio web:http://www.sigte.udg.edu/jornadassiglibre Síguenos en:https://twitter.com/SIGLibreGirona ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Debate con topónimo catalán (Sant Quirze del Vallès)
Hola a todos, Sin ánimo de que se produzca una discusión tan encarnizada como ya ha pasado con la Wikipedia (esto no, por favor!), me gustaría saber vuestras opiniones respecto al topónimo del municipio catalán Sant Quirze del Vallès, ya que este municipio ha empezado una campaña para que dejen de denominarlo en la red San Quirico de Tarrasa[1]. Más que aportar datos, dejo el enlace de la página de la discusión en la Wikipedia, el tema no es fácil y allí están todas las explicaciones y enlaces[2]. De entre todos los enlaces me ha llamado la atención uno, de una edición del periódico La Vanguardia de 1976 en que la noticia es que se cambia la denominación de San Quirico de Tarrasa a San Quirce del Vallés[3]. En OpenStreetMap lo tenemos como: - name=Sant Quirze del Vallès - name:es=San Quirico de Tarrasa Aprovechando que en OSM disponemos de más matices, yo propongo cambiarlo por: - name=Sant Quirze del Vallès - name:es=San Quirce del Vallés - old_name:es=San Quirico de Tarrasa Evidentemente antes de editar nada, me ha parecido que era importante comentarlo aquí. Muchas gracias! [1] http://santquirzevalles.cat/DetallNoticia/_CR1bHNtBU9DLTRiyiCrCY0_Hn-EWp_H1maQjpuC3t4E [2] https://es.wikipedia.org/wiki/Discusi%C3%B3n:San_Quirico_de_Tarrasa [3] http://hemeroteca.lavanguardia.com/preview/1976/03/20/pagina-32/33777815/pdf.html -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma de Cervelló www.konfraria.org • @La_Konfraria http://twitter.com/La_Konfraria ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Debate con topónimo catalán (Sant Quirze del Vallès)
Aprovechando que en OSM disponemos de más matices, yo propongo cambiarlo por: - name=Sant Quirze del Vallès - name:es=San Quirce del Vallés - old_name:es=San Quirico de Tarrasa Yo estoy de acuerdo, me parece lo más correcto. Como gallego también tenemos los mismos problemas y parece la mejor manera de tener la máxima información. -- Brais Arias Rio ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Debate con topónimo catalán (Sant Quirze del Vallès)
También de acuerdo. El 15 de noviembre de 2013 18:32, Brais Arias Rio braisar...@gmail.comescribió: Aprovechando que en OSM disponemos de más matices, yo propongo cambiarlo por: - name=Sant Quirze del Vallès - name:es=San Quirce del Vallés - old_name:es=San Quirico de Tarrasa Yo estoy de acuerdo, me parece lo más correcto. Como gallego también tenemos los mismos problemas y parece la mejor manera de tener la máxima información. -- Brais Arias Rio ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Debate con topónimo catalán (Sant Quirze del Vallès)
On 15/11/13 19:04, Javier Sánchez wrote: También de acuerdo. En principio de acuerdo, pero no del todo. Habría que añadir name:ca con el mismo contenido que name . Noel er Envite ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Debate con topónimo catalán (Sant Quirze del Vallès)
Aprovechando que en OSM disponemos de más matices, yo propongo cambiarlo por: - name=Sant Quirze del Vallès - name:es=San Quirce del Vallés - old_name:es=San Quirico de Tarrasa Creo que es bastante acertado, ecuánime, incluso políticamente correcto, y no dudo que habrá quien encuentre motivos para ofenderse o molestarse por algún matiz completamente invisible a los ojos del resto del universo. Pero por mi es perfecto. Hay topónimos que no solo están en desuso sino que son desconocidos en castellano. Se me ocurre Sant Feliu de Guixols, Lloret de Mar... ¿Tuvieron una versión castellana de su nombre? Pero sobre todo, ¿Como los llama hoy la gente?. Por ejemplo Lérida puede oirse por ese nombre y por Lleida, Gerona o Girona, pero nadie diria el Aeropuerto del Prado del Gato Lúgubre Belloc, Puigvert, tampoco han cambiado jamás su nombre (que yo sepa) ...en fin, el que le puso San Quirico debia estar lobotomizado. Es mi modesta opinión, pero si no os gusta, tampoco tengo otra. :) ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Mappen von Stiegen (als Teil der Adresse)
korrigiert mich bitte, wenn ich mich irre, aber im Sinne der redundanten Information wäre die unit Angabe korrekt. Wenn ich (als Paradebeispiel) den Karl-Marx-Hof in Wien nehme. Unzählige Stiegen mit einer Adresse in der Heiligenstädterstraße, mit weiteren Adressen in der Boschstraße und vielen Adressen in kleinen Gassen die beide genannten verbinden. Die Heiligenstädterstraße 82-92 müsste den gesamten Gebäudekomplex referenzieren (ca. 1,1 km). Die Unit zeigt direkt zur Stiege (also einen Teilbereich) - ev. zum Eingang. Doppeladressen dürften dann auch nur auf jene Stiegen verweisen (also wieder Teilbereiche des gesamten Wohnbaukomplexes) die in unmittelbarer Nähe zu jener Gasse sind. (Es wäre Sinnfrei die nördlichste Stiege mit der südlichsten Hausnummer anzugeben, dass man als Fußgänger dann noch 1km durch den Bau gehen darf, statt einfach drei Haltestellen später aus der Bim auszusteigen und gleich bei der gewünschten Adresse zu landen) Wenn die Adresse jedoch nur als markierter Punkt an der Stelle X angesehen wird und es keine Relationen zu irgendetwas anderem gibt, ist es meines erachtens durchaus legitim jede Information in die housenumber hinein zu schreiben. Nur so als denkanstoß, denn der is_in tag wird auch von Navis verwendet, zeigt aber redundante Informationen und ist daher unerwünscht - wenn auch (dzt.) sehr wichtig (Vergleich Navi - Nominatim) Am 15.11.2013 08:52 schrieb Martin Vonwald imagic@gmail.com: Da sich bisher keiner dazu durchringen konnte, die eindeutig falsche Angabe im Wiki (addr:housenumber ist definitiv kein Konsens für die Stiegennummer) wieder zu entfernen, habe ich dies nun erledigt - möglichst neutral mit beiden Varianten. Das das keine langfristige Llösung ist sollte klar sein und ich unterstütze definitiv die klare Aussage, dass ausschließlich addr:unit dafür zu verwenden ist. Martin [1] http://wiki.openstreetmap.org/wiki/WikiProject_Austria#Adressen ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ID_wo_ist_geoimage
Zur Info: Ab jetzt sollte geoimage.at in Österreich wieder als Layer im iD-Editor zur Auswahl stehen. Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it-trentino] Fwd: Workshop su OSM in Trentino
Da: girarsi_liste liste.gira...@gmail.com Ciao, devo segnalare, che nella slide N° 29, ovvero l'ultima, la voceFile con tutte le forestali trentine, trae in inganno, il file dei dati trentini al momento non è aggiornato per tutte le forestali, escluse quelle per esbosco che ovviamente sono costruite di anno in anno in base alla zona hai ragione va sicuramente corretto. Ciao Pietro ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [Talk-ro] [RFC] Detecție erori în codurile poștale
Lista e updatata constant? Momentan m-am uitat la http://www.openstreetmap.org/browse/way/245844791 care are deja addr:city pus. Daca nu e updatata constant, nu inseamna ca eventual o sa devina foarte confuz care sunt gata si care nu? Rares 2013/11/13 Strainu strain...@gmail.com În data de 13 noiembrie 2013, 02:12, Filip Chirita Rares Cristian chirita.ra...@gmail.com a scris: Salut, Pot sa te rog sa ne dai si un exemplu de corectat? Poate mintea mea nu merge calumea momentan, dar nu imi dau seama de unde sa incep. Sa zicem pentru nodul asta: http://www.openstreetmap.org/browse/node/769289252 ce pot sa fac? Sa ma duc si sa pun addr:in_city = oras? Rares Mai trimisesem un mail de dimineață, dar s-a pierdut. Da, în principiu trebuie adăugate datele lipsă, is_in:city sau addr:city. Uite câte un exemplu pentru fiecare tip de eroare: E1: http://www.openstreetmap.org/browse/changeset/18875399 E2, W3: http://www.openstreetmap.org/browse/changeset/18875478 W4: http://www.openstreetmap.org/browse/changeset/18875518 (aici era numărul trecut la cod) E4: http://www.openstreetmap.org/browse/node/1109599781 Sunt și unele pentru care nu se poate/nu e evident să corectezi, de exemplu: http://openstreetmap.org/browse/node/610916914 Trebuie analizat de la caz la caz. Strainu 2013/11/13 Strainu strain...@gmail.com Update: Am terminat partea de scanare a codurilor din OSM și am pus niște rezultate parțiale (scanare doar pentru addr:postcode pe noduri) la https://wiki.openstreetmap.org/wiki/Romanian_Postal_Codes Încă nu fac verificări cu datele de la poștă, sunt doar erori din OSM. De notat că am modificat un pic codurile de eroare pentru o mai bună consecvență în notație: E1: uNu pot extrage orașul din datele OSM, E2: uNu pot extrage strada din datele OSM, W3: uNu pot extrage numărul din datele OSM, W4: uCodul poștal e invalid, conține mai puțin de 6 cifre, E4: uCodul poștal e invalid (conține altceva decât 6 cifre), E5: uNu găsesc codul poștal în datele de la date.gov.ro , W6: uExistă greșeli în spellingul orașului, E6: uOrașul nu corespunde între OSM și date.gov.ro, W7: uSunt greșeli în spellingul străzii, E7: uStrada nu corespunde între OSM și date.gov.ro, E8: uNumărul/blocul nu corespund între OSM și date.gov.ro, Mi-au atras atenția câteva chestii: * Sunt foarte multe erori E1, ceea ce înseamnă că nu se practică punerea orașului în adresă. Știu că cineva a mai întrebat pe listă dacă e chiar necesar și v-am spus atunci că e nevoie pentru căutări după o anumită cheie. Uite că am dat chiar peste o asemenea situație :) Poate la un moment dat voi face o căutare în zonă ca să detectez orașul, dar deocamdată codurile respective nu vor fi verificare. * Sunt câteva coduri poștale puse de Michael pe noduri din way-uri cu numere cu valoarea unterschiedlich (diferite, dacă nu mă înșală traducerea automată). Michael, le pui manual sau le pune vreo unealtă? Dacă sunt manuale, care e rolul lor? Un nod reprezintă un număr, deci ar trebui să aibă un singur cod, nu? * Ce alte câmpuri/informații ar mai fi util să pun? Spor la corectat :) Strainu În data de 11 noiembrie 2013, 13:24, Strainu strain...@gmail.com a scris: Salut, Ca primă fază a importului codurilor poștale de la date.gov.ro, aș vrea să generăm o listă cu erori. Mai jos voi descrie procedura pe care vreau să o urmez, atât pentru a primi feedback, cât și pentru a o avea scrisă undeva. 1. Extrag toate nodurile și căile cu coduri poștale și încerc să extrag orașul, strada și numărul; dacă se poate, extrag și numele blocului. În cazul numerelor de casă care nu sunt formate doar din cifre, iau primul număr din text dacă începe de la caracterul 0 (adică 1A și 1BIS sunt 1, dar A1 e eroare) - pentru noduri folosesc is_in:city sau addr:city, addr:street, respectiv addr:housenumber - pentru căi folosesc is_in:city, name sau addr:street, respectiv addr:housenumber (dacă avem addr:street) - pentru coduri poștale folosesc postal_code sau addr:postcode 2. Pentru fiecare cod poștal, identific toate intrările din lista de la date.gov.ro și pentru fiecare dintre ele încerc să fac matching pe: a. oraș; dacă reușesc, merg la b.; dacă nu reușesc, eroare E6. b. stradă; dacă reușesc, merg la c.; dacă nu reușesc, eroare E8. c. număr; dacă reușesc, succes; dacă nu reușesc, merg la d. d. numele blocului; dacă reușesc, succes; dacă nu reușesc, eroare E10. Din descriere, complexitatea ar fi pătratică; practic, se poate optimiza mult aici. Tipurile de erori aruncate ar fi (E - eroare care nu poate fi evitată, W - eroare care poate fi evitată): E1. Nu pot extrage orașul din datele OSM E2. Nu pot extrage strada din datele OSM W3. Nu pot
Re: [Talk-ro] [RFC] Detecție erori în codurile poștale
Când o să termin de scris codul o să încerc și să-l fac să ruleze constant. Până atunci, e updatată când am ceva nou implementat. Strainu În data de 15 noiembrie 2013, 12:44, Filip Chirita Rares Cristian chirita.ra...@gmail.com a scris: Lista e updatata constant? Momentan m-am uitat la http://www.openstreetmap.org/browse/way/245844791 care are deja addr:city pus. Daca nu e updatata constant, nu inseamna ca eventual o sa devina foarte confuz care sunt gata si care nu? Rares 2013/11/13 Strainu strain...@gmail.com În data de 13 noiembrie 2013, 02:12, Filip Chirita Rares Cristian chirita.ra...@gmail.com a scris: Salut, Pot sa te rog sa ne dai si un exemplu de corectat? Poate mintea mea nu merge calumea momentan, dar nu imi dau seama de unde sa incep. Sa zicem pentru nodul asta: http://www.openstreetmap.org/browse/node/769289252 ce pot sa fac? Sa ma duc si sa pun addr:in_city = oras? Rares Mai trimisesem un mail de dimineață, dar s-a pierdut. Da, în principiu trebuie adăugate datele lipsă, is_in:city sau addr:city. Uite câte un exemplu pentru fiecare tip de eroare: E1: http://www.openstreetmap.org/browse/changeset/18875399 E2, W3: http://www.openstreetmap.org/browse/changeset/18875478 W4: http://www.openstreetmap.org/browse/changeset/18875518 (aici era numărul trecut la cod) E4: http://www.openstreetmap.org/browse/node/1109599781 Sunt și unele pentru care nu se poate/nu e evident să corectezi, de exemplu: http://openstreetmap.org/browse/node/610916914 Trebuie analizat de la caz la caz. Strainu 2013/11/13 Strainu strain...@gmail.com Update: Am terminat partea de scanare a codurilor din OSM și am pus niște rezultate parțiale (scanare doar pentru addr:postcode pe noduri) la https://wiki.openstreetmap.org/wiki/Romanian_Postal_Codes Încă nu fac verificări cu datele de la poștă, sunt doar erori din OSM. De notat că am modificat un pic codurile de eroare pentru o mai bună consecvență în notație: E1: uNu pot extrage orașul din datele OSM, E2: uNu pot extrage strada din datele OSM, W3: uNu pot extrage numărul din datele OSM, W4: uCodul poștal e invalid, conține mai puțin de 6 cifre, E4: uCodul poștal e invalid (conține altceva decât 6 cifre), E5: uNu găsesc codul poștal în datele de la date.gov.ro, W6: uExistă greșeli în spellingul orașului, E6: uOrașul nu corespunde între OSM și date.gov.ro, W7: uSunt greșeli în spellingul străzii, E7: uStrada nu corespunde între OSM și date.gov.ro, E8: uNumărul/blocul nu corespund între OSM și date.gov.ro, Mi-au atras atenția câteva chestii: * Sunt foarte multe erori E1, ceea ce înseamnă că nu se practică punerea orașului în adresă. Știu că cineva a mai întrebat pe listă dacă e chiar necesar și v-am spus atunci că e nevoie pentru căutări după o anumită cheie. Uite că am dat chiar peste o asemenea situație :) Poate la un moment dat voi face o căutare în zonă ca să detectez orașul, dar deocamdată codurile respective nu vor fi verificare. * Sunt câteva coduri poștale puse de Michael pe noduri din way-uri cu numere cu valoarea unterschiedlich (diferite, dacă nu mă înșală traducerea automată). Michael, le pui manual sau le pune vreo unealtă? Dacă sunt manuale, care e rolul lor? Un nod reprezintă un număr, deci ar trebui să aibă un singur cod, nu? * Ce alte câmpuri/informații ar mai fi util să pun? Spor la corectat :) Strainu În data de 11 noiembrie 2013, 13:24, Strainu strain...@gmail.com a scris: Salut, Ca primă fază a importului codurilor poștale de la date.gov.ro, aș vrea să generăm o listă cu erori. Mai jos voi descrie procedura pe care vreau să o urmez, atât pentru a primi feedback, cât și pentru a o avea scrisă undeva. 1. Extrag toate nodurile și căile cu coduri poștale și încerc să extrag orașul, strada și numărul; dacă se poate, extrag și numele blocului. În cazul numerelor de casă care nu sunt formate doar din cifre, iau primul număr din text dacă începe de la caracterul 0 (adică 1A și 1BIS sunt 1, dar A1 e eroare) - pentru noduri folosesc is_in:city sau addr:city, addr:street, respectiv addr:housenumber - pentru căi folosesc is_in:city, name sau addr:street, respectiv addr:housenumber (dacă avem addr:street) - pentru coduri poștale folosesc postal_code sau addr:postcode 2. Pentru fiecare cod poștal, identific toate intrările din lista de la date.gov.ro și pentru fiecare dintre ele încerc să fac matching pe: a. oraș; dacă reușesc, merg la b.; dacă nu reușesc, eroare E6. b. stradă; dacă reușesc, merg la c.; dacă nu reușesc, eroare E8. c. număr; dacă reușesc, succes; dacă nu reușesc, merg la d. d. numele blocului; dacă reușesc, succes; dacă nu reușesc, eroare E10. Din descriere, complexitatea ar fi pătratică;
Re: [Talk-lv] cemety.lv
Nu visādā ziņā ja viņi mūsu ziņu neņems vērā tad jau var to padot tālāk un osm legal listi un palūgt nobloķēt viņu servera IP, jo viņi jau visu tiles trafiku laiž caur savu serveri, lai nebūtu https warning'u :) Vajadzētu sastādīt smuku/pieklājīgu e-pastu un palūgt viņus darīt visu korekti. Lauris 2013. gada 14. novembris 19:34 Rich ric...@nakts.net rakstīja: On 11/14/2013 07:23 PM, Pēteris Brūns wrote: Domāju, ka neviens to nav sazinājies. Es gan piemetīšu eļļu ugunij. Tādas JS bibliotekas kā OpenLayers un Leflet, OSM slānim by defult met klāt atsauci (viņi vienu no šiem izmanto). Ir jāpacenšas viņu noņemt vai vismaz modificēt. zinu - bet tavs mails var nonaakt pie kaada, kursh nav saistiits ar nonjemshanu un neko nezina par taadaam detaljaam, jo izstraadi outsourceejis kaadam citam :) ... -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] proposed ceļi
+1 par kontroli un +/- vadlīnijām ko tad liekam kā proposed. Ļoti šaubos vai ir jēga likt kaut ko, kas ir desmitgades sapņi. Tuvāko 2-3 gadu plānos esošos objektus gan varētu. Īpaši iesaku neuzticēties teritorijas plānojumos esošajiem plānotajiem ceļiem, īpaši visādu ciemu un mazpilsētiņu apvedceļiem, ja vien tam nav vēl kāds stingrs pamats. Tur var gadīties visādi ar vieglu roku ievilkti deputātu sapņi. 2013/11/15 Viesturs Zarins viest...@gmail.com Jā lai gan personīgi nevienu tādu neesmu zīmējis, bet proposed ceļi domāju ir noderīgi. Jā tā ir renderu problēma ka viņi propsed ceļus zīmē kā īstus. Jāsazinās ar navigācijas programmu izsrādātājiem. Jā, kautkādu kontroli vajag. Vienkāršākais variants ir paziņot ka nepieciešams pievienot source= tagu visiem proposed ceļu autoriem. Pēc mēneša izdzēst tos kas nav pielikuši. Viesturs 2013/11/15 Marat mar...@gmail.com Ari esmu pret fantāziju augļus :) Daudziem pats source=* ar linku uz dokumentu/plānu nav uzlīkts Pēteris, es varu atzīmēt kādu personīgo sapņu ceļu caur Rīgas centru? :D 2013/11/15 Normunds Rustanovics trak...@gmail.com Mans piedāvājums bija ieviest kaut kādas minimālās prasības lai ceļu drīksētu atstāt. T.i. piemēram norādīt avotu, kur ir minēts, ka tāds ceļš ir plānots, un kad. N. On 15 Nov 2013, at 09:21, pec...@gmail.com wrote: Tas ir labāks jautājums. Pēc noklusētā likuma tam īsti vietas uz kartes nav. Domājams ka varētu izņemt. P. 2013. gada 15. novembris 09:20 Normunds Rustanovics trak...@gmail.comrakstīja: Tev ir jebkāds arguments priekš kam rādīt fantāziju augļus, kuriem nav saiknes ar realitāti? N. On 15 Nov 2013, at 09:18, pec...@gmail.com wrote: Salabot programmas un renderus. P. 2013. gada 15. novembris 08:53 Normunds Rustanovics trak...@gmail.comrakstīja: Sveiki Listē! Vēlētos uzsākt diskusiju par “proposed” ceļiem. Vajadzētu ieviest kaut kādus ierobežojumus, cik reāli plānotus ceļus vajag zīmēt uz kartes. Piemēram “Rietumu Maģistrāle” ir pavisam nereāls fantāziju auglis, kuru “izpīpēja” kaut kāds arhitektu birojs, doma bija šoseju taisīt pa virsu dzelzceļa sliedēm. Šobrīd nav nekāda pamata domāt, ka tas tiešām tiks realizēts, kā sākotnējie piedāvāts (lai arī internetā atrodamas norādes, uz to, ka tas joprojām ir kaut kādā 2018. gada dokumentā). Turklāt, vakar veicot salīdzinājumu starp vairākām OpenStreetmap navigācijas programmām telefonos, secināju, ka “proposed” ceļi nereti tiek rādīti un uztverti kā reāli eksistējoši ceļi. Tā protams ir programmatūras autoru kļūda, taču vēl viens faktors ko ņemt vērā. Līdz ar to mans jautājums — kāda ir jēga no šo ceļu attēlošanas? Es varu pieņemt, ka kartē ir ceļi, kuru būvniecība ir uzsākta, vai drīz tiks uzsākta, taču šobrīd kartē ir pat ceļu varianti (skat Kleistos), kas tikai rada lieku neizpratni un izrādās arī jauc navigācijas programmām “galvu”. N. ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- mortigi tempo Pēteris Krišjānis -- mortigi tempo Pēteris Krišjānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] proposed ceļi
Labdien! Savulaik jau minēju, ka proposed ceļus vajadzētu likt iekšā tikai relatīvi neilgi pirms reālo būvdarbu uzsākšanas, kad jau ir skaidri zināmas gaidāmo ceļu atrašanās vietas. Jāņem vērā, ka šie ziemeļu koridori un austrumu drēbju skapji bieži vien ir vēlēšanu kampaņu stratēģija, lai piesaistītu publicitāti. Tad, kad būs izstrādāti rasējumi ar ietvēm, komunikācijām utt (nevis ar sarkanu marķieri novilktas līnijas caur dzīvojamajām ēkām), rīkoti konkursi utt, tad arī varētu zīmēt kaut vai abstraktus ceļus, ja nav pieejama precīzāka informācija. Ir svarīgi iekļaut tādus datus, kam ir pamats ticēt, nevis tos datus, uz ko ir neliela cerība, ka kaut kad nākotnē varbūt ķersies klāt. 2013/11/15 Pēteris Brūns peteris.br...@gmail.com +1 par kontroli un +/- vadlīnijām ko tad liekam kā proposed. Ļoti šaubos vai ir jēga likt kaut ko, kas ir desmitgades sapņi. Tuvāko 2-3 gadu plānos esošos objektus gan varētu. Īpaši iesaku neuzticēties teritorijas plānojumos esošajiem plānotajiem ceļiem, īpaši visādu ciemu un mazpilsētiņu apvedceļiem, ja vien tam nav vēl kāds stingrs pamats. Tur var gadīties visādi ar vieglu roku ievilkti deputātu sapņi. 2013/11/15 Viesturs Zarins viest...@gmail.com Jā lai gan personīgi nevienu tādu neesmu zīmējis, bet proposed ceļi domāju ir noderīgi. Jā tā ir renderu problēma ka viņi propsed ceļus zīmē kā īstus. Jāsazinās ar navigācijas programmu izsrādātājiem. Jā, kautkādu kontroli vajag. Vienkāršākais variants ir paziņot ka nepieciešams pievienot source= tagu visiem proposed ceļu autoriem. Pēc mēneša izdzēst tos kas nav pielikuši. Viesturs 2013/11/15 Marat mar...@gmail.com Ari esmu pret fantāziju augļus :) Daudziem pats source=* ar linku uz dokumentu/plānu nav uzlīkts Pēteris, es varu atzīmēt kādu personīgo sapņu ceļu caur Rīgas centru? :D 2013/11/15 Normunds Rustanovics trak...@gmail.com Mans piedāvājums bija ieviest kaut kādas minimālās prasības lai ceļu drīksētu atstāt. T.i. piemēram norādīt avotu, kur ir minēts, ka tāds ceļš ir plānots, un kad. N. On 15 Nov 2013, at 09:21, pec...@gmail.com wrote: Tas ir labāks jautājums. Pēc noklusētā likuma tam īsti vietas uz kartes nav. Domājams ka varētu izņemt. P. 2013. gada 15. novembris 09:20 Normunds Rustanovics trak...@gmail.comrakstīja: Tev ir jebkāds arguments priekš kam rādīt fantāziju augļus, kuriem nav saiknes ar realitāti? N. On 15 Nov 2013, at 09:18, pec...@gmail.com wrote: Salabot programmas un renderus. P. 2013. gada 15. novembris 08:53 Normunds Rustanovics trak...@gmail.com rakstīja: Sveiki Listē! Vēlētos uzsākt diskusiju par proposed ceļiem. Vajadzētu ieviest kaut kādus ierobežojumus, cik reāli plānotus ceļus vajag zīmēt uz kartes. Piemēram Rietumu Maģistrāle ir pavisam nereāls fantāziju auglis, kuru izpīpēja kaut kāds arhitektu birojs, doma bija šoseju taisīt pa virsu dzelzceļa sliedēm. Šobrīd nav nekāda pamata domāt, ka tas tiešām tiks realizēts, kā sākotnējie piedāvāts (lai arī internetā atrodamas norādes, uz to, ka tas joprojām ir kaut kādā 2018. gada dokumentā). Turklāt, vakar veicot salīdzinājumu starp vairākām OpenStreetmap navigācijas programmām telefonos, secināju, ka proposed ceļi nereti tiek rādīti un uztverti kā reāli eksistējoši ceļi. Tā protams ir programmatūras autoru kļūda, taču vēl viens faktors ko ņemt vērā. Līdz ar to mans jautājums -- kāda ir jēga no šo ceļu attēlošanas? Es varu pieņemt, ka kartē ir ceļi, kuru būvniecība ir uzsākta, vai drīz tiks uzsākta, taču šobrīd kartē ir pat ceļu varianti (skat Kleistos), kas tikai rada lieku neizpratni un izrādās arī jauc navigācijas programmām galvu. N. ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- mortigi tempo Pēteris Krišjānis -- mortigi tempo Pēteris Krišjānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] proposed ceļi
Gluži manas domas, tāda arī bija mana pamatdoma. Sliktākais ir, ka tiek zīmēti ne tikai reklāmas kampaņu projekti uz 2020. gadu, bet arī tādi, kuri jau ir atcelti, vai aizvietoti ar citiem plāniem. N. On 15 Nov 2013, at 10:57, Jānis Ročāns janis.roc...@gmail.com wrote: Labdien! Savulaik jau minēju, ka proposed ceļus vajadzētu likt iekšā tikai relatīvi neilgi pirms reālo būvdarbu uzsākšanas, kad jau ir skaidri zināmas gaidāmo ceļu atrašanās vietas. Jāņem vērā, ka šie ziemeļu koridori un austrumu drēbju skapji bieži vien ir vēlēšanu kampaņu stratēģija, lai piesaistītu publicitāti. Tad, kad būs izstrādāti rasējumi ar ietvēm, komunikācijām utt (nevis ar sarkanu marķieri novilktas līnijas caur dzīvojamajām ēkām), rīkoti konkursi utt, tad arī varētu zīmēt kaut vai abstraktus ceļus, ja nav pieejama precīzāka informācija. Ir svarīgi iekļaut tādus datus, kam ir pamats ticēt, nevis tos datus, uz ko ir neliela cerība, ka kaut kad nākotnē varbūt ķersies klāt. 2013/11/15 Pēteris Brūns peteris.br...@gmail.com +1 par kontroli un +/- vadlīnijām ko tad liekam kā proposed. Ļoti šaubos vai ir jēga likt kaut ko, kas ir desmitgades sapņi. Tuvāko 2-3 gadu plānos esošos objektus gan varētu. Īpaši iesaku neuzticēties teritorijas plānojumos esošajiem plānotajiem ceļiem, īpaši visādu ciemu un mazpilsētiņu apvedceļiem, ja vien tam nav vēl kāds stingrs pamats. Tur var gadīties visādi ar vieglu roku ievilkti deputātu sapņi. 2013/11/15 Viesturs Zarins viest...@gmail.com Jā lai gan personīgi nevienu tādu neesmu zīmējis, bet proposed ceļi domāju ir noderīgi. Jā tā ir renderu problēma ka viņi propsed ceļus zīmē kā īstus. Jāsazinās ar navigācijas programmu izsrādātājiem. Jā, kautkādu kontroli vajag. Vienkāršākais variants ir paziņot ka nepieciešams pievienot source= tagu visiem proposed ceļu autoriem. Pēc mēneša izdzēst tos kas nav pielikuši. Viesturs 2013/11/15 Marat mar...@gmail.com Ari esmu pret fantāziju augļus :) Daudziem pats source=* ar linku uz dokumentu/plānu nav uzlīkts Pēteris, es varu atzīmēt kādu personīgo sapņu ceļu caur Rīgas centru? :D 2013/11/15 Normunds Rustanovics trak...@gmail.com Mans piedāvājums bija ieviest kaut kādas minimālās prasības lai ceļu drīksētu atstāt. T.i. piemēram norādīt avotu, kur ir minēts, ka tāds ceļš ir plānots, un kad. N. On 15 Nov 2013, at 09:21, pec...@gmail.com wrote: Tas ir labāks jautājums. Pēc noklusētā likuma tam īsti vietas uz kartes nav. Domājams ka varētu izņemt. P. 2013. gada 15. novembris 09:20 Normunds Rustanovics trak...@gmail.com rakstīja: Tev ir jebkāds arguments priekš kam rādīt fantāziju augļus, kuriem nav saiknes ar realitāti? N. On 15 Nov 2013, at 09:18, pec...@gmail.com wrote: Salabot programmas un renderus. P. 2013. gada 15. novembris 08:53 Normunds Rustanovics trak...@gmail.com rakstīja: Sveiki Listē! Vēlētos uzsākt diskusiju par “proposed” ceļiem. Vajadzētu ieviest kaut kādus ierobežojumus, cik reāli plānotus ceļus vajag zīmēt uz kartes. Piemēram “Rietumu Maģistrāle” ir pavisam nereāls fantāziju auglis, kuru “izpīpēja” kaut kāds arhitektu birojs, doma bija šoseju taisīt pa virsu dzelzceļa sliedēm. Šobrīd nav nekāda pamata domāt, ka tas tiešām tiks realizēts, kā sākotnējie piedāvāts (lai arī internetā atrodamas norādes, uz to, ka tas joprojām ir kaut kādā 2018. gada dokumentā). Turklāt, vakar veicot salīdzinājumu starp vairākām OpenStreetmap navigācijas programmām telefonos, secināju, ka “proposed” ceļi nereti tiek rādīti un uztverti kā reāli eksistējoši ceļi. Tā protams ir programmatūras autoru kļūda, taču vēl viens faktors ko ņemt vērā. Līdz ar to mans jautājums — kāda ir jēga no šo ceļu attēlošanas? Es varu pieņemt, ka kartē ir ceļi, kuru būvniecība ir uzsākta, vai drīz tiks uzsākta, taču šobrīd kartē ir pat ceļu varianti (skat Kleistos), kas tikai rada lieku neizpratni un izrādās arī jauc navigācijas programmām “galvu”. N. ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- mortigi tempo Pēteris Krišjānis -- mortigi tempo Pēteris Krišjānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- Jānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org
Re: [Talk-lv] proposed ceļi
On 11/15/2013 11:00 AM, Normunds Rustanovics wrote: Gluži manas domas, tāda arī bija mana pamatdoma. Sliktākais ir, ka tiek zīmēti ne tikai reklāmas kampaņu projekti uz 2020. gadu, bet arī tādi, kuri jau ir atcelti, vai aizvietoti ar citiem plāniem. ideja par source= taga prasiibu man patika. varbuut kaads aktiivaaks var izpeetiit visus proposed un tiem, kam nav source, pazinjot autoram. ja kaada aplikaacija raada proposed, noteikti, noteikti zinjojam aplikaacijas autoram. ja zinaami konkreeti ieziimeeti, bet atcelti gadiijumi, iemetam info sheit. ja vien neizraadaas, ka tomeer nav atcelti, jaanes nost. ... -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] proposed ceļi
Pilnīgi piekrītu Jānim. OSM jāatzīmē tie ceļi, kas top vai būs tuvākā gada laikā. Piemēram, tagad ir iezīmēts plānots 6. tramvaja maršruta pagarinājums, bet dabā it nekas par to neliecina. Esošais tramvaja ceļš ir pilnīgi pabeigts, bet par topošo nekas neliecina. Labdien! Savulaik jau minēju, ka proposed ceļus vajadzētu likt iekšā tikai relatīvi neilgi pirms reālo būvdarbu uzsākšanas, kad jau ir skaidri zināmas gaidāmo ceļu atrašanās vietas. Jāņem vērā, ka šie ziemeļu koridori un austrumu drēbju skapji bieži vien ir vēlēšanu kampaņu stratēģija, lai piesaistītu publicitāti. Tad, kad būs izstrādāti rasējumi ar ietvēm, komunikācijām utt (nevis ar sarkanu marķieri novilktas līnijas caur dzīvojamajām ēkām), rīkoti konkursi utt, tad arī varētu zīmēt kaut vai abstraktus ceļus, ja nav pieejama precīzāka informācija. Ir svarīgi iekļaut tādus datus, kam ir pamats ticēt, nevis tos datus, uz ko ir neliela cerība, ka kaut kad nākotnē varbūt ķersies klāt. 2013/11/15 Pēteris Brūns peteris.br...@gmail.com +1 par kontroli un +/- vadlīnijām ko tad liekam kā proposed. Ļoti šaubos vai ir jēga likt kaut ko, kas ir desmitgades sapņi. Tuvāko 2-3 gadu plānos esošos objektus gan varētu. Īpaši iesaku neuzticēties teritorijas plānojumos esošajiem plānotajiem ceļiem, īpaši visādu ciemu un mazpilsētiņu apvedceļiem, ja vien tam nav vēl kāds stingrs pamats. Tur var gadīties visādi ar vieglu roku ievilkti deputātu sapņi. 2013/11/15 Viesturs Zarins viest...@gmail.com Jā lai gan personīgi nevienu tādu neesmu zīmējis, bet proposed ceļi domāju ir noderīgi. Jā tā ir renderu problēma ka viņi propsed ceļus zīmē kā īstus. Jāsazinās ar navigācijas programmu izsrādātājiem. Jā, kautkādu kontroli vajag. Vienkāršākais variants ir paziņot ka nepieciešams pievienot source= tagu visiem proposed ceļu autoriem. Pēc mēneša izdzēst tos kas nav pielikuši. Viesturs 2013/11/15 Marat mar...@gmail.com Ari esmu pret fantāziju augļus :) Daudziem pats source=* ar linku uz dokumentu/plānu nav uzlīkts Pēteris, es varu atzīmēt kādu personīgo sapņu ceļu caur Rīgas centru? :D 2013/11/15 Normunds Rustanovics trak...@gmail.com Mans piedāvājums bija ieviest kaut kādas minimālās prasības lai ceļu drīksētu atstāt. T.i. piemēram norādīt avotu, kur ir minēts, ka tāds ceļš ir plānots, un kad. N. On 15 Nov 2013, at 09:21, pec...@gmail.com wrote: Tas ir labāks jautājums. Pēc noklusētā likuma tam īsti vietas uz kartes nav. Domājams ka varētu izņemt. P. 2013. gada 15. novembris 09:20 Normunds Rustanovics trak...@gmail.comrakstīja: Tev ir jebkāds arguments priekš kam rādīt fantāziju augļus, kuriem nav saiknes ar realitāti? N. On 15 Nov 2013, at 09:18, pec...@gmail.com wrote: Salabot programmas un renderus. P. 2013. gada 15. novembris 08:53 Normunds Rustanovics trak...@gmail.com rakstīja: Sveiki Listē! Vēlētos uzsākt diskusiju par proposed ceļiem. Vajadzētu ieviest kaut kādus ierobežojumus, cik reāli plānotus ceļus vajag zīmēt uz kartes. Piemēram Rietumu Maģistrāle ir pavisam nereāls fantāziju auglis, kuru izpīpēja kaut kāds arhitektu birojs, doma bija šoseju taisīt pa virsu dzelzceļa sliedēm. Šobrīd nav nekāda pamata domāt, ka tas tiešām tiks realizēts, kā sākotnējie piedāvāts (lai arī internetā atrodamas norādes, uz to, ka tas joprojām ir kaut kādā 2018. gada dokumentā). Turklāt, vakar veicot salīdzinājumu starp vairākām OpenStreetmap navigācijas programmām telefonos, secināju, ka proposed ceļi nereti tiek rādīti un uztverti kā reāli eksistējoši ceļi. Tā protams ir programmatūras autoru kļūda, taču vēl viens faktors ko ņemt vērā. Līdz ar to mans jautājums -- kāda ir jēga no šo ceļu attēlošanas? Es varu pieņemt, ka kartē ir ceļi, kuru būvniecība ir uzsākta, vai drīz tiks uzsākta, taču šobrīd kartē ir pat ceļu varianti (skat Kleistos), kas tikai rada lieku neizpratni un izrādās arī jauc navigācijas programmām galvu. N. ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- mortigi tempo Pēteris Krišjānis -- mortigi tempo Pēteris Krišjānis ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv -- pb ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...
Et comme ça ? http://openstreetmap.fr/blogs/cquest/wheelchair-overpass Si j'ai ajouté sur le rendu FR au dernier niveau de zoom ces détails c'est en attendant de produire un véritable rendu orienté handicap. C'est pas idéal, mais mieux que rien et surtout ça permet d'épater la galerie des décideurs ;) Pour les trottoirs j'ai modifié le rendu FR pour qu'il prenne en compte le tag footway=* qui était décrit dans le wiki et déjà utilisé pour masquer les footway=sideway et footway=crossing avant le zoom 18. Ca permet de garder le rendu des footway aux zooms précédents et de ne rendre visible ces micro-chemins que là où ils ne viennent plus trop se mélanger avec le reste de la voirie. En fait, c'est un problème de généralisation cartographique... et il faut bien quelques attributs pour aider à faire le tri. Le 15 novembre 2013 08:03, JB jb...@mailoo.org a écrit : Avec ce sujet politiquement incorrect, je m'étais posé la question du rendu handicap moteur (adapté dès les échelles intermédiaire, pas un saupoudrage aux zooms 19 à 28). Ce que j'avais dans la tête, c'était de partir du rendu standard noir et blanc, et de coloriser les objets accessibles/adaptés. Mais bon, j'ai jamais réussi à importer une base Pg sous Windows, et le projet est resté à l'état de projet. Mais si quelqu'un veut essayer avant que Windows aime Postgré… JB. Le 15.11.2013 05:58, Ista Pouss a écrit : Le 15 novembre 2013 00:01, Christian Quest cqu...@openstreetmap.fr a écrit : Je sais, c'est pas super explicite... la bande noire c'est l'ombre de la marche du trottoir, car wheelchair=no ;) Si quelqu'un a une meilleure idée, je suis preneur ! Je pense que ça ne sert à rien de placer les trucs d'handicap sur une carte générale : le handicap est un puits sans fond, et tout le monde s'en fout, sauf pour gagner son paradis ou pour avoir des budgets. Par contre il peut être très utile de faire des cartes à rendu spécialisé par type de handicap. Là on peut avoir une réflexion sur un handicap précis : comment les handicapés concernés peuvent lire le terrain, comment leur problématique peut être source de réflexion pour tout le monde. Pour la carte générale, ce qui est important, c'est le passage route/trottoir. Ce point est loin d'être résolu, à ce que j'ai compris. Mais quand même, pour une carte handicap mobilité, comment faire le rendu, allez vous me dire ?... Il me semble que pour les trottoirs, aux plus gros niveaux de zoom il y a la place pour le pictogramme de mobilité : http://wiki.openstreetmap.org/wiki/FR:Key:wheelchair ... et ne rien mettre si wheelchair=limited (de toutes manières je ne vois pas comment cette valeur peut s'appliquer à un trottoir). Et donc, ne pas montrer le wheelchair pour les trottoirs dès que le zoom diminue... idéalement, dès que le zoom ne permet plus de dessiner les particularités du trottoir. Cordialement. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Appel à bénévoles
Salut, Étant étudiant à l'n7, j'y ai un compte, donc un accès WiFi (de merde), mais ça peut dépanner je ne sais pas pas. Mon PC ne supporte pas l'AdHoc mais si celui de quelqu'un le supporte ça devrait le faire. Léo Le 15/11/2013 01:36, Sébastien Dinot a écrit : Vincent Privat a écrit : Je serai dispo pour l'atelier :) Je suis partant pour la même orga que l'an dernier ça marchait plutôt bien ;) Cool ! Merci. Entre toi, Christophe (orhygine), Cyrille, et deux autres personnes qui m'ont dit en privé pouvoir venir (mais pour au moins l'une d'entre elles, pas sur toute la durée de l'atelier). Nous atteignons le nombre d'animateurs que j'espérais. Reste à savoir désormais si, comme l'année dernière, nous aurons 25 personnes dans le public, voire plus. Sébastien -- Léo SERRE 06.18.62.32.05 leo-serre.legtux.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] gestion des listes locales
Salut, voici plusieurs fois que nous sommes amenés à modérer des messages sur la liste locale npdc d'osm et à chaque fois, malgré la libération des messages, ils ne sont jamais renvoyés sur la liste avez-vous déjà rencontré ce souci? qui gère les listes dans l'asso? et qui pourrait nous aider à corriger ce bug? merci à tous @+ adrien -- http://www.virage-energie-npdc.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...
Le 15 novembre 2013 09:27, Christian Quest cqu...@openstreetmap.fr a écrit : C'est pas idéal, mais mieux que rien et surtout ça permet d'épater la galerie des décideurs ;) Au sujet des décideurs je viens de tomber là dessus : Open Data camp organisé par Etalab le 28/11 à Paris à https://commons.wikimedia.org/wiki/Commons:Bistro#Open_Data_camp_organis.C3.A9_par_Etalab_le_28.2F11_.C3.A0_Paris C'est hors sujet et probablement que vous connaissez déjà, mais c'est juste décideurs :-) Bon, je sors, promis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Appel à bénévoles
sébastien, as tu besoin que j'amène une machine pour le stand ? Le 14 nov. 2013 01:52, Sébastien Dinot sebastien.di...@free.fr a écrit : Bonsoir, Léo SERRE a écrit : Je réitère, je serais là samedi, mais pas dimanche. C'est bien ce que j'avais noté. Mais merci d'avoir confirmé ta présence. Je pense présenter une webapp basée sur OSM entre autre. OK, de mon côté, j'apporterai un PC vieillissant mais compact (et donc facile à transporter) et qui devrait suffire pour les démos. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Appel à bénévoles
Salut, - Mail original - sébastien, as tu besoin que j'amène une machine pour le stand ? Si tu peux, ce serait cool. De mon côté, la seule machine facilement transportable dont je dispose est un vieux Dell OptiPlex GX620 : http://reviews.cnet.com/desktops/dell-optiplex-gx620/4505-3118_7-31420314.html C'est pratique sur un stand car l'ensemble est compact et l'écran (atypique car au format 5/4 pour une définition de 1280x1024 pixels) est relativement haut (par rapport à celui d'un portable sur lequel on se voûte toujours) mais ce PC n'est doté que d'un Pentium 4 HT à 3 GHz et de 1 Go de RAM. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] gestion des listes locales
Je confirme, nous avons le même problème sur la liste local-marseille. De mémoire, Olivier Griffet (modérateur sur local-marseille et présent sur cette liste) avait signalé le problème et il était déjà connu. D'habitude, dans le mail de modération, je clique sur le lien qui va sur l'interface d'admin et je là je clique sur distribuer et ça a l'air de marcher (pas d'erreur) mais le mail n'arrive jamais sur la liste. Récemment, j'ai essayé de cliquer sur le lien mailto: (celui qui envoie un mail avec DISTRIBUTE xxx en titre) et là j'ai reçu une réponse Undelivered Mail Returned to Sender contenant ça : Command output: /usr/lib/sympa/bin/queue: while opening queue file 'T.sympa.1384009998.6273': Permission denied Probablement une piste à creuser... Cordialement Gilles Le 15/11/2013 10:40, adrien carpentier a écrit : Salut, voici plusieurs fois que nous sommes amenés à modérer des messages sur la liste locale npdc d'osm et à chaque fois, malgré la libération des messages, ils ne sont jamais renvoyés sur la liste avez-vous déjà rencontré ce souci? qui gère les listes dans l'asso? et qui pourrait nous aider à corriger ce bug? merci à tous @+ adrien -- http://www.virage-energie-npdc.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Suivi cours d'eau
Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo j'essairai de mettre à jour régulièrement cordialement Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag pour Maison des Associations de Solidarité ?
Le Thu, 14 Nov 2013 13:20:40 +0100, Pieren pier...@gmail.com a écrit : Suite à cette 'note': http://www.openstreetmap.org/?note=73172 je me demandais comment on taggue une Maison des Associations de Solidarité qui met à disposition 8 salles toutes en lumière du jour, dont 6 salles de sous commission et un espace événementiel entièrement équipé pour que chacune de vos manifestations soit une totale réussite.: http://www.mas-paris.fr/ J'utilise amenity=community_centre pour les centres d'animation mais je ne crois pas que ça s'applique aussi à ce genre de structure. Ca me fait penser un peu à la cantine du silicon sentier, non ? C'est bizarrement taggué en amenity=cafe... Il y a autre chose à prendre en compte à propos de cette structure, c'est qu'elle héberge aussi des bureaux permanents pour quelques associations du champ de la solidarité : http://www.mas-paris.fr/qui.html Après, de là à avoir un tag spécifique... -- Emmanuel Lesouef gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C gpg keyid : 6613EB6C signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi cours d'eau
Bonjour, le 15/11/2013 16:03, claude marani a écrit: Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo J'ai regardé vite faire la Seille en Saône-et-Loire. La longueur indiquée est 19km et ne correpsond pas à la réalité et à la relation dans OSM. Où est l'erreur ? Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Contours communes par départements
Bonjour, Il y a quelques temps, un contributeur de cette liste que je remercie encore m'a donné ce lien : http://export.openstreetmap.fr/contours-administratifs/communes/ Or, je constate que depuis quelques jours les fichiers sont corrompus. Juste quand j'en ai besoin à nouveau. C'est ennuyeux. Savez-vous pourquoi ? Quelqu'un aurait-t-il par hasard enregistré les limites communales des départements de Bourgogne et Franche-Comté sur son disque dur et pourrait me les envoyer ? Merci. -- Adrien Caillot ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi cours d'eau
Le vendredi 15 novembre 2013 16:52:52, Samy Mezani a écrit : Bonjour, le 15/11/2013 16:03, claude marani a écrit: Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo J'ai regardé vite faire la Seille en Saône-et-Loire. La longueur indiquée est 19km et ne correpsond pas à la réalité et à la relation dans OSM. Où est l'erreur ? Idem par ici pour la sèvre nantaise. L'outil indique 30km alors que la relation est plus proche des 150km. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi cours d'eau
Pareil pour l'Orne (41km selon courdo, 169.6 selon Wikipedia), le Golo (30 contre 89.6), ... Francescu Le 15 novembre 2013 17:23, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le vendredi 15 novembre 2013 16:52:52, Samy Mezani a écrit : Bonjour, le 15/11/2013 16:03, claude marani a écrit: Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo J'ai regardé vite faire la Seille en Saône-et-Loire. La longueur indiquée est 19km et ne correpsond pas à la réalité et à la relation dans OSM. Où est l'erreur ? Idem par ici pour la sèvre nantaise. L'outil indique 30km alors que la relation est plus proche des 150km. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi cours d'eau
toutes les longeurs sont fausse :( j'ai pas touché à la partie générant les longeur et je sais pas si mes compétences vont me permettre de corriger Le 15 novembre 2013 17:23, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le vendredi 15 novembre 2013 16:52:52, Samy Mezani a écrit : Bonjour, le 15/11/2013 16:03, claude marani a écrit: Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo J'ai regardé vite faire la Seille en Saône-et-Loire. La longueur indiquée est 19km et ne correpsond pas à la réalité et à la relation dans OSM. Où est l'erreur ? Idem par ici pour la sèvre nantaise. L'outil indique 30km alors que la relation est plus proche des 150km. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contours communes par départements
tiens je vais en profiter pour signaler aussi que le département des Deux-Sevres est rangé dans les incomplets... alors que j'ai l'impression qu'on a pas de frontières cassée et peut etre que c'est a cause des communes qui ont fusionné en début d'année et donc le script tombe pas sur le meme nombre de communes que ce qu'il a en base?... peut etre le meme cas est aussi pour d'autres département ayant des communes fusionnées... -- View this message in context: http://gis.19327.n5.nabble.com/Contours-communes-par-departements-tp5785593p5785611.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi cours d'eau
Le 15/11/2013 17:29, claude marani a écrit : toutes les longeurs sont fausse :( j'ai pas touché à la partie générant les longeur et je sais pas si mes compétences vont me permettre de corriger Le 15 novembre 2013 17:23, Stéphane Péneau stephane.pen...@wanadoo.fr mailto:stephane.pen...@wanadoo.fr a écrit : Le vendredi 15 novembre 2013 16:52:52, Samy Mezani a écrit : Bonjour, le 15/11/2013 16:03, claude marani a écrit: Bonjour le résultat généré par l'outil d'Arnaud Renevier modifié pour la France entière est visible ici http://marani.claude.free.fr/courdo J'ai regardé vite faire la Seille en Saône-et-Loire. La longueur indiquée est 19km et ne correpsond pas à la réalité et à la relation dans OSM. Où est l'erreur ? Idem par ici pour la sèvre nantaise. L'outil indique 30km alors que la relation est plus proche des 150km. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonsoir Je pense que c'est mieux après modifications la Seille 116 km L'Orne 192.4 km Le Golo 89.1 km La Sèvre nantaise 143 km c'est la longueur des relations. il manque certain cours d'eau dans l'index. va falloir que je regarde pourquoi cordialement Claude -- Envoyé avec Mozilla Thunderbird --- ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] AEDのタグ、アイコン
http://wiki.openstreetmap.org/wiki/Proposed_features/automated_external_defibrillator 見たのですが、AEDについては emergency=defibrillator にすれば良いのでしょうか。投票は終わったみたいですけれど、 これで確定したのかな。 確定していれば、入力しやすくなるのですが。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSRM-talk] Making progress on dumping pgRouting tables to OSRM
Hi Steve, We have succesfully used python (urllib2 and simplejson libs) for the HTTP connection to OSRM. We have gotten good response times - especially (of course) when PostgreSQL and OSRM are both on the same server. /Greg *Hans Gregers Petersen* Partner, Seniorkonsulent greg...@septima.dk -- Septima P/S Larsbjørnsstræde 3 1454 Kbh K www.septima.dk Tlf: +45 7230 0672 Cvr: 34900841 On 15 November 2013 03:25, Stephen Woodbridge wood...@swoodbridge.comwrote: Antonio, Thank you for the feedback on CURL, and the other references. I kind of look at the development path as get it working then figure out how to make it fast. Get it working allows use to validate the approach, but having feedback like this is great so we can avoid the same issues others have already discovered. I'll have to read up on the apache httpclient stuff. I have never seen that before. Did you write a wrapper for your requests to OSRM via httpclient? Can you share that? Thanks, -Steve On 11/13/2013 4:03 PM, Antonio Moratilla Ocaña wrote: Hi Stephen Only two notes that may help you with your plan: I've been working on using OSRM from a web service, and i've learned OSRM doesn't perform so good when queried with curl (Ok, it's not OSRM problem, but curl: it need to setup a route and connection to the server, and it takes time, and usually you don't go concurrent here). In my problem, i've been using apache commons httpclient in a concurrent fashion (http://hc.apache.org/httpcomponents-client-4.3.x/index.html , http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/examples/org/ apache/http/examples/client/ClientMultiThreadedExecution.java), so connections didn't get released: I was able to reach up to 700 request por second to my test server, but when used with curl (called from java), I couldn't go above 20 request per second. On the distance matrix topic, I remember Dennis talking about it some time ago, and, if i'm correct, he said he had implemented a really efficient method for matrix calculation using some clever ideas with OSRM internal data representation. He said that code was not open source (maybe some project/contract source code?. Later on, he said he had matrix calculation on target to be included on OSRM soon (maybe another source code version) https://github.com/DennisOSRM/Project-OSRM/issues/544, so it would be great if that feature could be added. You can also try Klopt (https://code.google.com/p/klopt/wiki/introduction , https://github.com/keesklopt/matrix) Good luck!!! Antonio Moratilla Ocaña - antonio.morati...@uah.es mailto:antonio.morati...@uah.es - Despacho N334 Profesor del Dpto. Ciencias de la Computación - http://www.cc.uah.es Escuela Politécnica - Informática - http://www.etsii.uah.es Universidad de Alcalá - http://www.uah.es 2013/11/13 Stephen Woodbridge wood...@swoodbridge.com mailto:wood...@swoodbridge.com On 11/13/2013 12:27 PM, Emil Tin wrote: Hi Stephen, Sound like very interesting work, conencting pgRouting and OSRM. I'm afraid I can't help you with your current problem, but I'm sure Dennis can. Emil Hi Emil, Dennis, Sorry, cross-posted to pgRouting-dev So this is kind of my rough plan. I have looked into how to do the various pieces and now it is just a matter of find some time to do the code and testing. 1. build a pgr2osrm tool that will dump a pgRouting topology into an OSRM intermediate file that can be built with osrm-prepare. This is the piece that I'm working on at the moment. 2. setup a local osrm-routed (should be trivial) 3. code postgresql stored procedures to talk to osrm-routed using libcurl 4. write stored procedures like: point = osrm_locate(point) point = osrm_nearest(point) jsontext = osrm_viaroute(point[], alt, instruction, zoom) status = osrm_getRouteStatus(jsontext); polyline = osrm_getRouteGeometry(__jsontext, alt) instructions[] = osrm_getRouteInstructions(__jsontext, alt) distancematrix[][] = osrm_dmatrix(points[]) distancerow[] = osrm_one2many(point, points[] To support this, it would be great if Dennis had time to add two methods to osrm-routed like: http://server:5000/dmatrix?__lat= http://server:5000/dmatrix?lat=latlon=lon... http://server:5000/one2many?__slat= http://server:5000/one2many?slat=start_latslon=start_ __lonlat=latlon=lon... where the list of points are the arguments. And if the we supply say 10 point, then we get back a 10 x 10 matrix. I can simulate this by making multiple calls to the server and trying to manage all the hints, but it would be far more efficient to just pass the array of points and let the server optimize caching internally. This would also decrease the number of requests to the server and the
[OSRM-talk] Update on OSRM-pgRouting integration
Hi all, Here is a demo of using OSRM and pgrouting using php to glue things together. http://imaptools.com:8081/demo/osrm.html Sorry for the weird test grid. The roads have some randomly assigned speed_cat and direction of travel which can make for some unexpected routes. When I have a chance I'll build a real work graph. Read the HELP that comes up when you load the page. Here is a description of how it works. The [Route Path] function just collects the marker locations and makes a direct call to the OSRM server. No magic there, you can look at the Javascript to see how to make Leaflet do that. I was going to add dragging the route or markers, but it more interesting to get this working in pgrouting. For the [Optimize *] functions, I call a PHP script to glue everything together for the moment. The basic logic is: 1. get and array of points 2. loop through the points calling OSRM N*(N-1) times to build a distance matrix and cache the result in an NxN array 3. call pgrouting pgr_tsp(dmatrix, start, stop) to get an ordered list of points 4. Get the cached route_geometry for the ordered pairs of nodes 5. return that as jsonp object. Time vs Distance Currently there is no easy way to ask OSRM to compute shortest time vs shortest distance. I understand that I might be able to do this using profile.lua files but this would require having two OSRM servers running using different profiles. For the time being, I compute a routes for the distance matrix calling OSRM and build my distance matrix based on the route_distance vs the route_time values returned in the request. Then TSP orders the nodes to minimize the cost values used. I suspect we would get different results if we could compute the routes based on either time or distance. My next step is to move the php code into C code in the database. And at some point build out a real road network for a better demo. -Steve ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[Talk-GB] OSSV impact on OSM GB
Hi, I've been working on trying to understand what impact OS OpenData had on OSM in the UK. As a first cut, I looked at all objects with the following properties in the gb history extract upto 2012: - version = 1 - name not equal to blank - highway = residential, footway, service, unclassified, track, tertiary, path, primary, secondary, trunk, road, motorway, motorway_link, primary_link Then I reduced each highway to its approximate point location and analyzed contributions over time. This produced the following map: http://i.imgur.com/9DuAqN5.png You can read a full description of my findings are method here: https://medium.com/p/75108bd65bcd I had a few questions for those that might've been around at that time: - does the chart intuitively make sense? are there any obvious errors on my part that I should take into consideration? - what explains certain regions getting a lot of new highways while other not? I'm talking about areas like Suffolk (but not Norfolk), Lancashire but not North Yorkshire? There are many such examples. - finally, what more analysis would one like to see? Let me know, I'm working on this data some more, so would be happy to produce more maps that would be useful to the community. Abhishek http://abhishek.mit.edu ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] OSSV impact on OSM GB
Probably one of the best example areas is Lincolnshire which was very poorly mapped indeed prior to OS Opendata or Bing imagery being available. Afterwards there was a push by some to at least get the road network in by armchair mapping. Any analysis like this needs to consider the timing of data release with what other data sources were in use or impacted the same time period and what was being discussed within the community (eg on the mailing list). In some case someone will have pointed out a need and others will have risen to the challenge of improving the map. Cheers Andy -Original Message- From: Borbus [mailto:bor...@gmail.com] Sent: 15 November 2013 15:47 To: talk-gb@openstreetmap.org Subject: Re: [Talk-GB] OSSV impact on OSM GB On 15/11/13 14:08, Abhishek wrote: - what explains certain regions getting a lot of new highways while other not? I'm talking about areas like Suffolk (but not Norfolk), Lancashire but not North Yorkshire? There are many such examples. Norfolk just didn't have any active mappers at that time. Norwich was fairly active, but most people who live in Norwich don't really consider themselves to live in Norfolk. It wasn't until 2011 that we got some good mappers in North Norfolk and we managed to get 100% completion on the ITO OSM analysis. I personally used OSSV extensively. PinkDuck didn't actually do the NAPTAN import, by the way. The edit which you are referring to was a tag change on all of the already imported relations if I remember correctly. -- Borbus. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Upcoming changes to OpenStreetMap.org website
(The aim of this email is to provide prior knowledge of an upcoming change to the OSM website and to give you an opportunity to provide constructive feedback) (I posted this email to the talk mailing list last Tuesday. Since then we had some great feedback and changes have been made to the design. As we move closer to this change, I felt it appropriate to communicate this change to the local GB list.) Hi All, Today the updated design for the main OpenStreetMap.org website is nearly ready to be rolled out. You can view a demo atredesign.apis.dev.openstreetmap.org and you can read about the latest changes on the “pull request” at: https://github.com/openstreetmap/openstreetmap-website/pull/498#issuecomment-28309700 This is the cumulation of many months of work starting with Saman's presentation at State of the Map US 2013. Obviously I realise that not everyone has the time to search for all the background in the mailing lists and github pull request so to help I have collated the video and slides from both SotM US 2013 and SotM 2013 athttp://2013.stateofthemap.org/blog/upcoming-changes-openstreetmaporg-website/ Please take a minute or two to give it a try – both positive feedback and constructive criticism is welcomed. Note: The test server running at the link below is separate from the rest of the osm.org website. As such, you will need to set up new user account if you want to test out how the website functions for logged in users. Furthermore the history results will not show much! http://redesign.apis.dev.openstreetmap.org Regards, RobJN Final acceptance is by the OpenStreetMap Foundation and it's Working Groups. The work of the Foundation and the Working Groups is explained at:http://2013.stateofthemap.org/blog/work-openstreetmap-foundation/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Locations for State of the Map US 2014
How about Tulsa, Oklahoma? Closest major metro area to the lower 48's centroid. Can't get much more heartland than that. On Wednesday, November 13, 2013, Eric Theise wrote: No question DC could host SotM US in style, but I'd be thrilled to see it move to the heartland. Too big of a stretch for it to be in Chicago? ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
Then that kind of eliminates everything but Oklahoma from the running. Most affordable state in the nation. On Wednesday, November 13, 2013, Alex Barth wrote: Expenses for attendees are a concern in both places, we want to make sure SOTM-US is as inclusive as possible and this means folks with smaller budgets shouldn't be left out. We're running these numbers right now. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. -- Richie Kennedy www.route56.com * richiekenned...@gmail.com facebook.com/route56 * twitter.com/route56 I'm not crazy. I'm just ahead of my time. From: Paul Johnson Sent: Friday, November 15, 2013 10:19 AM To: OpenStreetMap talk-us list How about Tulsa, Oklahoma? Closest major metro area to the lower 48's centroid. Can't get much more heartland than that.___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
It would be nice to have the SOTM-US within driving distance from Denver, but I enjoy the travel too. I'd suggest Philly if I wanted to get a bid together, but I don't think I'll be doing that this year. I would love to see some good bids this year, and hopefully if those bids aren't selected, the information can be updated for next year's bidding. On Fri, Nov 15, 2013 at 10:28 AM, richiekenned...@gmail.com wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. -- Richie Kennedy www.route56.com * richiekenned...@gmail.com facebook.com/route56 * twitter.com/route56 I'm not crazy. I'm just ahead of my time. *From:* Paul Johnson ba...@ursamundi.org *Sent:* Friday, November 15, 2013 10:19 AM *To:* OpenStreetMap talk-us list talk-us@openstreetmap.org How about Tulsa, Oklahoma? Closest major metro area to the lower 48's centroid. Can't get much more heartland than that. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
Just to remind everyone, we have a sign in the Fremont neighborhood of Seattle that claims it is the Center of the Universe. On Fri, Nov 15, 2013 at 3:23 PM, Paul Johnson ba...@ursamundi.org wrote: On Friday, November 15, 2013, wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. Just going by the claims of some random KDOT sign along US 169 nearish Caney, stating it's at the geographic center of the lower 48th. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
Sorry, the center of the universe is in Tulsa on the pedestrian bridge across the railroad tracks downtown. Also, Postgres tells me that the geographic center of the lower 48 is at 39.5359,-99.1558 (ish) Yours in precision, -Nathan Clifford Snow cliff...@snowandsnow.us wrote: Just to remind everyone, we have a sign in the Fremont neighborhood of Seattle that claims it is the Center of the Universe. On Fri, Nov 15, 2013 at 3:23 PM, Paul Johnson ba...@ursamundi.org wrote: On Friday, November 15, 2013, wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. Just going by the claims of some random KDOT sign along US 169 nearish Caney, stating it's at the geographic center of the lower 48th. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
If those KDOT signs are near Meades Ranch then they are likely correct. https://en.wikipedia.org/wiki/Meades_Ranch%2C_Kansas -- Sent from my mobile device. Please excuse my brevity. Paul Johnson ba...@ursamundi.org wrote: On Friday, November 15, 2013, wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. Just going by the claims of some random KDOT sign along US 169 nearish Caney, stating it's at the geographic center of the lower 48th. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
Yeah, second this statement, I regularly take out of town guests to the Center of the Universe, particularly if we're on a pub crawl and need a cab (since there's few cabbies that don't know where the center of the universe or the airport are). On Fri, Nov 15, 2013 at 5:45 PM, Nathan Mills nat...@nwacg.net wrote: Sorry, the center of the universe is in Tulsa on the pedestrian bridge across the railroad tracks downtown. Also, Postgres tells me that the geographic center of the lower 48 is at 39.5359,-99.1558 (ish) Yours in precision, -Nathan Clifford Snow cliff...@snowandsnow.us wrote: Just to remind everyone, we have a sign in the Fremont neighborhood of Seattle that claims it is the Center of the Universe. On Fri, Nov 15, 2013 at 3:23 PM, Paul Johnson ba...@ursamundi.orgwrote: On Friday, November 15, 2013, wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. Just going by the claims of some random KDOT sign along US 169 nearish Caney, stating it's at the geographic center of the lower 48th. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Clifford OpenStreetMap: Maps with a human touch -- Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
I got Caney and Coffeyville backwards. They're roughly midway between Coffeyville, KS and South Coffeyville, Oklahoma on US 169, IIRC ( http://www.openstreetmap.org/?relation=129916#map=13/37.0054/-95.6294). I know when I saw them, they were surprisingly far south for what I thought. I strongly suspect KDOT has posted a number of conflicting landmarks (similar albeit slightly less inconsistent situation would be ODOT's posting of 45th Parallel signs, many of which, particularly in the desert, are off by up to a mile, and likely posted in the wrong spot intentionally to give tourists a spot to pull out and stop; you learn to hate the tourists that stop at the accurate ones because they're putting you and the rest of the public in danger, like this moron standing in the middle of I 5 near Keizer, Oregon: http://confluence.org/us/or/n45w123v7/pic2.jpg) On Fri, Nov 15, 2013 at 5:56 PM, Tod Fitch t...@fitchdesign.com wrote: If those KDOT signs are near Meades Ranch then they are likely correct. https://en.wikipedia.org/wiki/Meades_Ranch%2C_Kansas -- Sent from my mobile device. Please excuse my brevity. Paul Johnson ba...@ursamundi.org wrote: On Friday, November 15, 2013, wrote: Seeing as how the “official” location of the lower 48’s centroid is in north-central Kansas, I’d have to dispute your claim that Tulsa is the closest major metro area. Looks to me that Lincoln, Nebraska would be the closest. There’s also Wichita, Omaha, Topeka, and Kansas City. Just going by the claims of some random KDOT sign along US 169 nearish Caney, stating it's at the geographic center of the lower 48th. -- Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
On 11/15/13 6:39 PM, Clifford Snow wrote: Just to remind everyone, we have a sign in the Fremont neighborhood of Seattle that claims it is the Center of the Universe. yeah, but i live a short distance away from a community with a sign that proudly announces that it's the only Stephentown on earth. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
On Fri, Nov 15, 2013 at 3:45 PM, Nathan Mills nat...@nwacg.net wrote: Sorry, the center of the universe is in Tulsa on the pedestrian bridge across the railroad tracks downtown. Also, Postgres tells me that the geographic center of the lower 48 is at 39.5359,-99.1558 (ish) That is only the center of the lower 48. Fremont is the actual center of the universe. See http://dakinecascadia.files.wordpress.com/2010/08/fremont-center-of-universe1.jpgfor proof! -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Locations for State of the Map US 2014
This actually is the Center of the Universe ( http://urbane-chaos.hubpages.com/hub/TulsaCenteroftheUniverse), it's located in downtown Tulsa (http://osm.org/go/T4_e8jEsA?m=). There's even a festival there every summer (http://centeroftheuniversefestival.com/http://centeroftheuniversefestival.com/center-universe). CBS even situated a comedy around it ( https://en.wikipedia.org/wiki/Center_of_the_Universe_(TV_series)). On Fri, Nov 15, 2013 at 7:55 PM, Clifford Snow cliff...@snowandsnow.uswrote: On Fri, Nov 15, 2013 at 3:45 PM, Nathan Mills nat...@nwacg.net wrote: Sorry, the center of the universe is in Tulsa on the pedestrian bridge across the railroad tracks downtown. Also, Postgres tells me that the geographic center of the lower 48 is at 39.5359,-99.1558 (ish) That is only the center of the lower 48. Fremont is the actual center of the universe. See http://dakinecascadia.files.wordpress.com/2010/08/fremont-center-of-universe1.jpgfor proof! -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
