Re: [Talk-vi] Dự án bản đồ Việt Nam và cộng đồng người dùng tại Việt Nam?
Giao lưu tí, bác đang ở đâu thế? Melbourne à? 2014-09-09 20:03 GMT+07:00 Vũ Phạm Minh Tuấn vutuan...@gmail.com: Chào các bạn, các anh chị em đang dùng OSM, Mình tham gia OSM đã lâu và vẫn thường xuyên cập nhật bản đồ cho khu vực Việt Nam và các quốc gia lân cận. Tính đến nay cũng đã hơn 2 năm làm cộng tác viên, cũng có nhiều buồn vui, nhưng mình vẫn đam mê và xem OSM như món ngon tinh thần bổ ích. Duy có điều cộng đồng người dùng OSM ở Việt Nam có lẽ hơi trầm so với vài cộng đồng khác. Sự trầm lặng đó khiến cho chúng ta không giải quyết được một số vấn đề đang tồn tại trong Dự án Bản đồ Việt Nam này, và cũng như trong cộng đồng người dùng. 1/ Không Đồng bộ cách dùng : cách đánh cấp bậc của Highway, Thành phố, thị trấn... gần như tùy thuộc vào ý muốn chủ quan cá nhân. Trong khi đó bảng phân loại hiện giờ không đầy đủ, khiến cho người dùng không biết tra cứu để áp dụng cho đồng bộ. Cho đến nay đã có 1 bảng xếp hạng 10 thang bậc admin_level (để đánh cấp bậc cho Boundary - ranh giới), nhưng ta còn thiếu cách xếp hạng tương tự cho phân loại đường phố, Địa danh v.v... 2/ Không cập nhật : Nhà nước, cụ thể là Bộ GTVT đã ban hành quy định phân loại và đặt số hiệu đường bộ. Chẳng hạn : QL cho Quốc lộ. Vd : QL.1A ĐT cho đường tỉnh, tỉnh lộ. Vd : ĐT.587 cho đường tỉnh 587. ĐH cho đường huyện. Vd : ĐH.02. Dựa vào đó, nhiều tỉnh thành đã và đang ban hành cách định danh mới, hoặc đổi tên/số toàn bộ, hoặc đánh số mới cho các Đường tỉnh. Như vậy, danh xưng 'Tỉnh lộ' xem như không hợp pháp và ko còn đúng với thực tế. 3/ Không tương tác : Vì không có quy ước nào cụ thể nên các thành viên đôi khi tùy tiện đưa ra cách làm riêng, dẫn tới phá vỡ hoặc làm hỏng đi ý nghĩa của bản đồ. Chúng ta cần 1 lực lượng phụ trách review và kiểm tra các tiêu chuẩn để bảo đảm thông tin được ngay hàng thẳng lối. 4/ Thiếu hiệu quả : - Vì thiếu nhân lực và tiêu chuẩn phân loại nên không có động lực hoàn thiện bản đồ. Mọi thứ đều tùy theo đóng góp của người dùng cá nhân. Nhiều khu vực đô thị, thị trấn chưa được vẽ lên, và có lẽ sẽ không bao giờ được vẽ nếu không ai quan tâm dành thời gian cho nó. Vì vậy, tôi đề nghị : - Cần bắt đầu thảo luận về các nội dung trên bản đồ VN, cụ thể là rà soát và phân định các tiêu chí, tiêu chuẩn cho khớp với thực trạng đường sá, nhà cửa, dịch vụ tại VN. - Xây dựng 1 nhóm người đại diện, gồm những ng tâm huyết nhất và có trách nhiệm để 'quản lý' việc đồng bộ các quá trình này, và quản lý mạng ng dùng ở VN. - Xây dựng Chiến lược vẽ bản đồ bài bản, nề nếp ; training tập huấn cho thành viên mới ; marketing, hỗ trợ ng dùng đầu cuối biết đến bản đồ OSM. Trên đây là vài ý kiến ngắn gọn của em về OSM tại VN, dựa trên những gì em quan sát và so sánh với OSM ở Úc và các nước bạn. Rất mong các anh chị nhiệt tình giúp đỡ và cho ý kiến để hoàn thiện bản đồ chúng ta. Trân trọng kính chào, *Tuấn* -- VU, PHAM MINH TUAN *(**Tony)* *vi : Vũ Phạm Minh Tuấn | **zh :* 武范明俊 *THE UNIVERSITY OF MELBOURNE* Graduate School of Humanities and Social Sciences *Master of International Relations* *Class of 2013* •*SSEAYP :* *35th-2008* (j,b,i,t,v,p) : Vpy, SG-I, DG-CCU. *39th-2012* (b,j) : V-Obsc. •*A*: 42 Ascot St, ASCOT VALE, VIC 3032, Australia. *M*: +61 421.125.385. *E*: vutuan...@gmail.com *FB http://www.facebook.com/tuanifan LinkedIn http://vn.linkedin.com/pub/minh-tuan-vu/40/462/831/ OpenStreetMap http://www.openstreetmap.org/user/Tuan%20Ifan%20Vpy* ___ Talk-vi mailing list Talk-vi@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-vi ___ Talk-vi mailing list Talk-vi@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-vi
Re: [talk-ph] SOTM-PH 2014?
Would not like to miss this like last time. Please make it SOTM-PH 2015... -- sent using mental telepathy via Ansible On Sep 9, 2014 6:10 PM, maning sambale emmanuel.samb...@gmail.com wrote: On Mon, Sep 8, 2014 at 9:27 PM, Eugene Alvin Villar sea...@gmail.com wrote: Why not SotM Asia? :-) Ack! Too much to handle this year. Maybe next year? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] SOTM-PH 2014?
Me t Q1 2015 would be nice, would try hardest to come up for that .. Regards Mark Cupitt If we change the world, let it bear the mark of our intelligence Hire Me on Freelancer See me on Open StreetMap https://www.openstreetmap.org/user/Mark_Cupitt See me on LinkedIn http://ph.linkedin.com/in/markcupitt *See me on StackExchange http://gis.stackexchange.com/users/17846/mark-c* === The contents of this email are intended only for the individual(s) to whom it is addressed and may contain confidential or privileged information. If you are not the intended recipient, you must not disclose, copy, distribute, or use the contents of this email. If you have received this email in error, please notify the sender immediately and delete the email and any attachments. === On Tue, Sep 9, 2014 at 10:11 PM, Erwin Olario gov...@gmail.com wrote: Would not like to miss this like last time. Please make it SOTM-PH 2015... -- sent using mental telepathy via Ansible On Sep 9, 2014 6:10 PM, maning sambale emmanuel.samb...@gmail.com wrote: On Mon, Sep 8, 2014 at 9:27 PM, Eugene Alvin Villar sea...@gmail.com wrote: Why not SotM Asia? :-) Ack! Too much to handle this year. Maybe next year? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Tubbataha is way off
Not as bad as the PH one thousand bill [0], but, Tubbataha [1] seems way of from satellite imagery [2] by ~14 km. Free beer or a drink of your choice to someone who can verify with gps tracks. ;) [0] http://en.wikipedia.org/wiki/Philippine_one_thousand_peso_bill#mediaviewer/File:New_PHP1000_Banknote_%28Reverse%29.jpg [1] http://www.openstreetmap.org/way/280149159 [2] https://farm4.staticflickr.com/3843/15008702547_903ca12979_o.png -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Fietspad - even verifieren
On Tuesday 09 September 2014 07:06:46 Marc Gemis wrote: Een afzonderlijk fietspad is voor mij ok, als alle verbindingen met de zijstraten en opritten opstaan en bicycle=no of use_sidepath op de hoofdbaan. Geen bicycle=no, daar hebben we al vaak genoeg over gediscussieerd dat dat niet correct is, bicycle=use_sidepath is de juiste :-) Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
Ik deel hier toch ook Marc zijn mening, het ziet er prima uit momenteel op voorwaarde dat het is afgewerkt. Denk dat het nuttiger is het bestaande werk aan te vullen dan opnieuw te doen. Bij wijze van test heb ik eens die N10 streek door de validator gehaald. Ben nog steeds bezig met correcties en aanvullingen na 30minuten. Ok, groot vierkant idd. Bekijk deze eens in de buurt: https://www.openstreetmap.org/way/5073848 hangt aan: https://www.openstreetmap.org/way/217844106 Yup, een highway aan admin level 7 ... die de weg volgt. Persoonlijk geef ik dit soort miskleumen de voorkeur. Ben nog steeds bezig met het 'effe 10m ontspannen met OSM fixes' ;-) Mvg, Glenn On 09-09-14 07:06, Marc Gemis wrote: Een afzonderlijk fietspad is voor mij ok, als alle verbindingen met de zijstraten en opritten opstaan en bicycle=no of use_sidepath op de hoofdbaan. Ik denk dat ze in Nederland en Duitsland ook meestal afzonderlijke fietspaden mappen. Maar de situaties en wetgeving zijn daar misschien wel net iets anders. met vriendelijke groeten m 2014-09-08 23:51 GMT+02:00 Ben Laenen benlae...@gmail.com mailto:benlae...@gmail.com: Voor mij is het even goed om het hier apart te tekenen. Al was het maar om het geen ratjetoe te maken met bijvoorbeeld de bushaltes een beetje verder naar het noordwesten waar dan wel weer scheiding moet zijn, en dan de kruispunten waar het ook apart van de weg is. Laat het er gewoon opstaan nu ze toch apart gemapt zijn. De fietspaden zijn heel nauwkeurig gemapt dus ga je werk van iemand teniet doen. Ben On Monday 08 September 2014 22:12:41 Johan Vervloet wrote: Dag lijst, De Antwerpsesteenweg in Lier ziet er als volgt uit: https://www.google.be/maps/@51.1445163,4.5447119,3a,90y,274.43h,79.62t/data= !3m4!1e1!3m2!1sgnxTXT_AZdr7FM20H_lAHQ!2e0 En hij is zo gemapt: https://www.openstreetmap.org/way/228603352#map=18/51.14361/4.54612 Heb ik het goed dat het aangeraden is om dat aparte fietspad te verwijderen, en cycleway:left en cycleway:right te gebruiken? Ik baseer me hiervoor op deze maillijstthread: https://lists.openstreetmap.org/pipermail/talk-be/2014-May/thread.html#5732 Groeten, Johan ___ Talk-be mailing list Talk-be@openstreetmap.org mailto: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 -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
On Tuesday 09 September 2014 14:32:25 Glenn Plas wrote: https://www.openstreetmap.org/way/5073848 hangt aan: https://www.openstreetmap.org/way/217844106 Yup, een highway aan admin level 7 ... die de weg volgt. Persoonlijk geef ik dit soort miskleumen de voorkeur. Ben nog steeds bezig met het 'effe 10m ontspannen met OSM fixes' ;-) Lang geleden werden de nodes van de wegen herbruikt om gemeentegrenzen te tekenen. Daar zijn we dan wel vanaf gestapt, maar dit is nog één van die overblijvende grenzen. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
Op 9 september 2014 07:06 schreef Marc Gemis marc.ge...@gmail.com: Een afzonderlijk fietspad is voor mij ok, als alle verbindingen met de zijstraten en opritten opstaan en bicycle=no of use_sidepath op de hoofdbaan. Ok, dankjewel voor de info. Johan ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
wat doe je met een straat die echt de grens is ? Afzonderlijke nodes maar de wegen over elkaar ? voorbeeld: http://osm.org/go/0EpG_cM4m?way=22920473 feitelijk stemt het stukje voor huisnummers 44-48 niet de werkelijkheid overeen. Beide gemeentes zijn verantwoordelijk voor de helft van de rijweg. Zo had enkele jaren geleden een van beide gemeentes een laag asfalt over zijn helft van de weg gelegd. De andere helft waren nog kasseien. Typisch Belgisch zeker ? :-) Nu ja, ik zou al blij zijn als Nominatim de huizen in de juiste gemeente zou plaatsen. Maar dat lukt ook niet 2014-09-09 14:38 GMT+02:00 Ben Laenen benlae...@gmail.com: On Tuesday 09 September 2014 14:32:25 Glenn Plas wrote: https://www.openstreetmap.org/way/5073848 hangt aan: https://www.openstreetmap.org/way/217844106 Yup, een highway aan admin level 7 ... die de weg volgt. Persoonlijk geef ik dit soort miskleumen de voorkeur. Ben nog steeds bezig met het 'effe 10m ontspannen met OSM fixes' ;-) Lang geleden werden de nodes van de wegen herbruikt om gemeentegrenzen te tekenen. Daar zijn we dan wel vanaf gestapt, maar dit is nog één van die overblijvende grenzen. Ben ___ 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] Fietspad - even verifieren
Ik heb ze ernaast gelegd zopas, dit gaat technisch gezien over centimeters (of 10), er is een functie voor in josm maar dan nog moet je alle nodes een offset geven of je krijgt een waarschuwing voor elke duplicate node(s) met verschillende tags. Ik probeer niet af te wijken van de originele situatie met uitzondering dat het voor de mapper na mij moet opvallen dat daar dubbele ways liggen. Glenn On 09-09-14 14:48, Marc Gemis wrote: wat doe je met een straat die echt de grens is ? Afzonderlijke nodes maar de wegen over elkaar ? voorbeeld: http://osm.org/go/0EpG_cM4m?way=22920473 feitelijk stemt het stukje voor huisnummers 44-48 niet de werkelijkheid overeen. Beide gemeentes zijn verantwoordelijk voor de helft van de rijweg. Zo had enkele jaren geleden een van beide gemeentes een laag asfalt over zijn helft van de weg gelegd. De andere helft waren nog kasseien. Typisch Belgisch zeker ? :-) Nu ja, ik zou al blij zijn als Nominatim de huizen in de juiste gemeente zou plaatsen. Maar dat lukt ook niet 2014-09-09 14:38 GMT+02:00 Ben Laenen benlae...@gmail.com mailto:benlae...@gmail.com: On Tuesday 09 September 2014 14:32:25 Glenn Plas wrote: https://www.openstreetmap.org/way/5073848 hangt aan: https://www.openstreetmap.org/way/217844106 Yup, een highway aan admin level 7 ... die de weg volgt. Persoonlijk geef ik dit soort miskleumen de voorkeur. Ben nog steeds bezig met het 'effe 10m ontspannen met OSM fixes' ;-) Lang geleden werden de nodes van de wegen herbruikt om gemeentegrenzen te tekenen. Daar zijn we dan wel vanaf gestapt, maar dit is nog één van die overblijvende grenzen. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org mailto: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 -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
Op 9 september 2014 14:48 schreef Marc Gemis marc.ge...@gmail.com: Nu ja, ik zou al blij zijn als Nominatim de huizen in de juiste gemeente zou plaatsen. Maar dat lukt ook niet Ik denk dat dat nu net te maken heeft met het verschuiven van de grenzen naar 1 kant (zelfs al is het maar 10cm). De Straat ligt dan volgens Nominatim in 1 gemeente, en als gevolg wordt het huis geclassificeerd in de gemeente van de straat. Niet dat ik zeg dat we daarom moeten taggen voor Nominatim (dat zou hetzelfde zijn als taggen voor de renderer), maar er zit wel een logica achter. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietspad - even verifieren
Ach, doordat de huizen ook nog eens in een associatedStreet-relatie zitten kijkt Nominatim naar het eerste segment en in welke gemeente dat segment ligt. Ik wil niet specifiek voor Nominatim taggen, waar wel zo dat geocoders de huizen in de juiste gemeente plaatsen. Ik geloof niet dat de andere geocoders het wel juist doen. Maar door een straat volledig binnen de grens van 1 gemeente te leggen, kan geen enkele geocoder de straat terugvinden in de andere gemeente. groeten m 2014-09-09 20:20 GMT+02:00 Sander Deryckere sander...@gmail.com: Op 9 september 2014 14:48 schreef Marc Gemis marc.ge...@gmail.com: Nu ja, ik zou al blij zijn als Nominatim de huizen in de juiste gemeente zou plaatsen. Maar dat lukt ook niet Ik denk dat dat nu net te maken heeft met het verschuiven van de grenzen naar 1 kant (zelfs al is het maar 10cm). De Straat ligt dan volgens Nominatim in 1 gemeente, en als gevolg wordt het huis geclassificeerd in de gemeente van de straat. Niet dat ik zeg dat we daarom moeten taggen voor Nominatim (dat zou hetzelfde zijn als taggen voor de renderer), maar er zit wel een logica achter. Groeten, Sander ___ 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
[OSM-talk-be] Destination tagging on motorways
In Nederland heb ik de snelwegen op veel plaatsen voorzien van bestemmingen. Als bijrijder ben ik in de gelegenheid geweest om afgelopen maand de bebording op de route Breda-Antwerpen-Gent-Kortrijk-Lille vice versa te fotograferen. Die wil ik graag op de manier zoals ik die in Nederland heb getagd gaan taggen. Dat houdt het volgende in: - invoeren destination details conform de werkwijze op http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details, inclusief het invoeren van het afritnummer met de tag junction:ref - het positioneren van de motorway_junction conform http://wiki.openstreetmap.org/wiki/Talk:Lane_assist/Examples/Motorway_exit, oftewel juist voor de doorgetrokken streep Het mooie van het toevoegen van de destinations is dat dit een stap is om een rijstrookassistent te krijgen in OSM. Mijn op OSM gebaaseerde Garmin is al in staat om de bestemmingen niet alleen weer te geven maar ook uit te spreken, wat erg handig is in drukke verkeerssituaties. Diverse andere OSM routeringsprogramma's ondersteunen de bestemmingen eveneens. Ik wil graag meehelpen om ook andere Belgische snelwegen te voorzien van de bestemmingen, maar op sommige Belgische snelwegen kom ik erg weinig tot nooit. Zouden jullie kunnen helpen door het nemen van foto's van de bebording cq het opnemen van ritten op de snelwegen met een dashcam? Met vriendelijke groet, Johan aka It's so funny ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Destination tagging on motorways
On Tuesday 09 September 2014 22:14:25 Johan C wrote: In Nederland heb ik de snelwegen op veel plaatsen voorzien van bestemmingen. Als bijrijder ben ik in de gelegenheid geweest om afgelopen maand de bebording op de route Breda-Antwerpen-Gent-Kortrijk-Lille vice versa te fotograferen. Die wil ik graag op de manier zoals ik die in Nederland heb getagd gaan taggen. Dat houdt het volgende in: - invoeren destination details conform de werkwijze op http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details, inclusief het invoeren van het afritnummer met de tag junction:ref De afritten zelf zouden er al moeten inzitten met hun naam en nummer onder highway=motorway_junction + ref=* + name=*. De exacte bestemmingen ontbreken inderdaad. Waar komt de junction:ref eigenlijk vandaan? Wel even de opmerking dat er verschil is tussen de naam van een afrit en de bestemming. Op deze borden http://nl.wikipedia.org/wiki/Bestand:Afrit-4-Oostende-A10.jpg zie je de naam, de blauwe borden met pijlen hebben de bestemming. Voor de rest: leef je maar uit :-) Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] tag with value lists Was: Proposed mechanical edit to convert alt_name tags
On Mon, Sep 08, 2014 at 02:23:40PM -0500, Andrew Buck wrote: Isnt the semicolon the list seperator typically used in OSM? My intuitive answer would have been alt_name=a;b;c;d Flo My understanding was that since almost nothing actually understands the ; separator that doing it as multiple tags is the preferred system. I think the ; separator is not really understood by nominatim, for example, whereas the multiple tags system is. I think nominatim might work with ; in a sort of hacky way since it probably will match on substrings, but it will confuse other parts of the system, not to mention all of the other systems that don't understand ; AFAIK Nominatim does fine with the semicolon. Mapnik breaks - so every information you think of putting on the map needs to be split before handed over to mapnik. In any case I don't really want to turn this into a discussion of how multiple values should be handled in general as this has been done before and no one has come to a solution. That is a discussion for a different time and place, this is just about remedying a minor inconsistency in the current tagging. I dont get this. It seems somebody rushed and imported stuff as alt_name:2 and when stepping back and thinking about it we are in a hurry again? Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Visually detect missing roads
I did announce this on the German list last week. As the load did not cause the server to catch fire I'm now announcing it to a wider audience. I have created a map which visually diffs our data against Google Maps. Currently it compares major highways (unclassified and higher) and water features. The data is styled to show up in bright colors. If there is matching data in OSM it would hide the Google data. So in a perfect area the map would be grey. Differences stay visible. You can try it here: http://compare.osm-tools.org/ It has the possibility to directly load the visible area into the editors. More details can be found here: http://www.osm-tools.org/compare.html or if you're able to read German in my blog post at http://www.technologyblog.de/2014/08/wo-fehlen-bei-openstreetmap-noch-daten/ In well-mapped areas the differences are usually caused by OSM data not being tagged as a major highway. If you're looking for areas where roads are actually missing and can be drawn from aerials head over to Asia. Hope this helps all people interested in arm-chair mapping to focus on the major missing parts of OSM-data. If you pan the map fast you'll see the original Google data. This is caused by the way technical way the images are layered. When using Google API instead of OpenLayers it would not do this but caching of tiles is worse with Google. That's why I decided to use OL. Enjoy mapping! Stephan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag with value lists Was: Proposed mechanical edit to convert alt_name tags
On Mon, Sep 08, 2014 at 05:52:57PM -0500, Andrew Buck wrote: On 09/08/2014 05:44 PM, Eugene Alvin Villar wrote: On Tue, Sep 9, 2014 at 3:00 AM, Florian Lohoff f...@zz.de wrote: Isnt the semicolon the list seperator typically used in OSM? My intuitive answer would have been alt_name=a;b;c;d +1 I think using a semicolon-delimited list is better than a potentially open-ended set of keys such as alt_name_x, and already has precedent. While it is true that semicolon as a multi-value separator is not written as a law of OSM tagging, it is quite frequent enough to be a de facto tagging guideline. Both systems are in use and were in use before we started working on this GNS stuff. The tiger tags are one example, but there were alt_name_N tags before we started as well. If you want to have a discussion about changing all of these worldwide, that is fine, but this thread is about fixing the alt_name:2 ones. Please either weigh in on that, or keep silent. I do not have time to have a general discussion about broader topics of how multi-valued keys should be handled. There have been dozens of threads that discussed that and no one has ever come up with a good solution, so I am not going to have this thread get dragged into the same discussion that has been had many times before. There has been one person who has said it makes sense to change them, and all of the other posts have been about discussion of other topics. So unless someone has some concrete reason _not_ to convert the few mistaken ones, I will go ahead and do that. We can have these other discussions some other time when people are not waiting on the results. Sorry, but this is not how OSM works. You have to allow discussion and you have to listen what people have to say and engage with them in the discussion. If you can not do that you can not do any automated edits. I understand your frustration with the discussion culture in OSM that often seems to go in endless rounds and leads nowhere, but for better or worse, this is what we have and what has built OSM as we know it. So somehow it can't be all bad. There are a lot of people on this mailing list with long experience in OSM and the software using its data. Chances are there are a few who know something you don't. It might appear tedious, but it actually leads somewhere. And if you want to help the discussion along, you can read all the answers and suggestions and pull them together into one coherent pro/contro-type document with the different proposals. Your argument that others are discussing a different topic is bogus. If you want to change alt_name:2 into alt_name_2 and people don't agree that this is the right tag, how can that be a different discussion? Btw I think you have a good chance that this discussion will lead somewhere, because you seem to be actually using those tags. Most endless discussions revolve around lofty issues where nobody actually uses any of the variants in question. So make your case, but keep an open mind, collect information about the solutions impartially and you will get somewhere. If you think you don't have the time, maybe you should think about the time of all the others involved here, too. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visually detect missing roads
It would be useful to allow switching between diff, OSM only and google only. Currently in my area results are too confusing to be useful. 2014-09-09 9:11 GMT+02:00 Stephan Knauss o...@stephans-server.de: I did announce this on the German list last week. As the load did not cause the server to catch fire I'm now announcing it to a wider audience. I have created a map which visually diffs our data against Google Maps. Currently it compares major highways (unclassified and higher) and water features. The data is styled to show up in bright colors. If there is matching data in OSM it would hide the Google data. So in a perfect area the map would be grey. Differences stay visible. You can try it here: http://compare.osm-tools.org/ It has the possibility to directly load the visible area into the editors. More details can be found here: http://www.osm-tools.org/compare.html or if you're able to read German in my blog post at http://www.technologyblog.de/2014/08/wo-fehlen-bei- openstreetmap-noch-daten/ In well-mapped areas the differences are usually caused by OSM data not being tagged as a major highway. If you're looking for areas where roads are actually missing and can be drawn from aerials head over to Asia. Hope this helps all people interested in arm-chair mapping to focus on the major missing parts of OSM-data. If you pan the map fast you'll see the original Google data. This is caused by the way technical way the images are layered. When using Google API instead of OpenLayers it would not do this but caching of tiles is worse with Google. That's why I decided to use OL. Enjoy mapping! Stephan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Visually detect missing roads
On 09/09/2014 08:11, Stephan Knauss wrote: I have created a map which visually diffs our data against Google Maps. I can see how Google could find this useful locally to me - it would enable them to remove some of the roads on their map that don't exist, like the one to a coal mine that closed in 1957 :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag with value lists Was: Proposed mechanical edit to convert alt_name tags
Isnt the semicolon the list seperator typically used in OSM? My intuitive answer would have been alt_name=a;b;c;d Isn't this sometimes going to cause issues when it comes to the number of characters? __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes in the rendering
Thanks for fixing it, but there's one problem remaining. There's a quite visible gap in rendering when moving from a highway+railway to a highway+railway+bridge. E.g. http://www.openstreetmap.org/?mlat=59.33140mlon=18.09368#map=19/59.33140/18.09368 /Markus On 10 August 2014 14:33, Matthijs Melissen i...@matthijsmelissen.nl wrote: On 10 August 2014 10:09, Markus Lindholm markus.lindh...@gmail.com wrote: - highway=platform is no longer rendered - railway=tram is no longer rendered if it shares a way with highway=* Are these bugs or a deliberate change? These are bugs, thanks for reporting. I created issues on Github for them: - https://github.com/gravitystorm/openstreetmap-carto/issues/871 - https://github.com/gravitystorm/openstreetmap-carto/issues/874 In general, if you want a quick response, it is easier to create the issues directly on Github as not all stylesheet maintainers follow the talk mailing list. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] 1.61 Gigapixel density map of the POI in Europe
If somebody find this interesting, i made a visualization of the POI in Europe https://www.openstreetmap.org/user/baditaflorin/diary/23729 http://t.signauxtrois.com/link?url=https%3A%2F%2Fwww.openstreetmap.org%2Fuser%2Fbaditaflorin%2Fdiary%2F23729ukey=agxzfnNpZ25hbHNjcnhyGAsSC1VzZXJQcm9maWxlGICAwKvb7u4KDAk=4deb11a0-66f0-4720-8978-390decfdd9dc have a good day, Florin Badita https://www.facebook.com/OsmRomania ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 1.61 Gigapixel density map of the POI in Europe
Looks very interesting for *most* of Europe. Signed, Iceland It is very nice though, showing the density in Central Europe, both due to population and very active OSM communities. div Upphafleg skilaboð /divdivFrá: Badita Florin baditaflo...@gmail.com /divdivDagsetning:10/09/2014 02:48 (GMT+00:00) /divdivTil: talk@openstreetmap.org /divdivEfni: [OSM-talk] 1.61 Gigapixel density map of the POI in Europe /divdiv /divIf somebody find this interesting, i made a visualization of the POI in Europe https://www.openstreetmap.org/user/baditaflorin/diary/23729 have a good day, Florin Badita https://www.facebook.com/OsmRomania ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes in the rendering
I opened a ticket: https://github.com/gravitystorm/openstreetmap-carto/issues/934 2014-09-09 23:35 GMT+02:00 Markus Lindholm markus.lindh...@gmail.com: Thanks for fixing it, but there's one problem remaining. There's a quite visible gap in rendering when moving from a highway+railway to a highway+railway+bridge. E.g. http://www.openstreetmap.org/?mlat=59.33140mlon=18.09368#map=19/59.33140/18.09368 /Markus On 10 August 2014 14:33, Matthijs Melissen i...@matthijsmelissen.nl wrote: On 10 August 2014 10:09, Markus Lindholm markus.lindh...@gmail.com wrote: - highway=platform is no longer rendered - railway=tram is no longer rendered if it shares a way with highway=* Are these bugs or a deliberate change? These are bugs, thanks for reporting. I created issues on Github for them: - https://github.com/gravitystorm/openstreetmap-carto/issues/871 - https://github.com/gravitystorm/openstreetmap-carto/issues/874 In general, if you want a quick response, it is easier to create the issues directly on Github as not all stylesheet maintainers follow the talk mailing list. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] GraphHopper em pt-br
bom dia, peço desculpas pelo meu português, ainda tão mal escrito. Falo um poquinho melhor, pq. morava um certo tempo no Brasil (o melhor - não no Brasil - foi em São Paulo ;-) ) mais - 'tou morrendo de saudade. :-) Eu moro agora na região de Hunsrück. ;-) --- tb. falo hunsrücksch ;-) Bom - então o meu assunto ... eu organiso a tradução do graphhopper. http://bit.ly/1uGNYtd Faltam so algumas palavras. Seria ótimo se alguém de Vcs poderia ajudar aqui http://bit.ly/1CM61na muito obrigado e até já -- ## Manfred ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] mapa da área Alcobaça, Jucuruçu e Santo Antônio do Jacinto
Hi Andreas, I second Gerald's comments and also would like to thank you for your contribution to OSM in Brazil. As you noticed we still have a lot to map and your contribution is valued! All the best, João PS: Just for a small clarification: I recommended Andreas to come to talk-br, since he posted some doubts at talk-de about street names in Brazil. Esclarecimento aos mapeadores: eu recomendei ao Andreas que se inscrevesse aqui na talk-br pois ele postou algumas dúvidas na talk-de sobre nomes de ruas brasileiras. 2014-09-08 23:17 GMT+02:00 Andreas Schmidt schmidt-postf...@freenet.de: Hello Gerald, thanks for your reply. Well, in the area where I live, most streets and amenities are fully mapped. So I started looking around for places with lower rate of coverage. I hit Brazil when I read news about robbery at Samsung's factory in Campinas. I was surprised that OSM did not cover this factory when I looked it up on OSM. So I started to map Campinas. Last week I realised, that some more main roads and rivers are not mapped. So I started somewhere (what I call the „nose“ of South America) in the area of Alcobaça. Then I continued westwards and I have a lot fun mapping the rivers which look very pretty because they are so natural. Sometimes I sit and watch Brazil's aerial imagery or map and I feel wanderlust. kind regards, Andreas Am 08.09.2014 um 22:42 schrieb Gerald Weber: Hi Andreas welcome to OSM Brasil. Feel free to write in English, a lot of us in this list will understand and reply. Any particular reason for your interest in those cities? best wishes Gerald 2014-09-08 17:31 GMT-03:00 Andreas Schmidt schmidt-postf...@freenet.de: Olá talk-br, Infelizmente eu não falam Português. Falo Inglês e Alemão. Agora eu uso o Google Translator. Olá João, você me escreveu em talk-de. Você disse, eu posso falar para br Relatório em Inglês ou Alemão. Eu vivo no norte da Alemanha e estou muito poucos anos no OSM. Eu uso JOSM e meu computador está funcionando com Linux Mint. Por cerca de uma semana que estou trabalhando no mapa da área Alcobaça, Jucuruçu e Santo Antônio do Jacinto. cumprimentos Andreas ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Fwd: e-SIC - Pedido Respondido
Oi pessoal, Recebemos a resposta de um novo pedido de informações para o processo de importação das bases da Prefeitura de São Paulo. Na primeira resposta eles pedem atribuição, mas não especificam como. O pessoal da lista *imports *pediu que a gente esclarecesse isto com a prefeitura e a prefeitura deu a resposta abaixo. Eles não responderam exatamente a pergunta feita, mas acho que podemos avançar com a importação considerando que podemos fazer uma atribuição no wiki e na página de copyright que atenda aos requerimentos da última resposta. As páginas do wiki das importações são: https://wiki.openstreetmap.org/wiki/Geolog_PMSP_Import https://wiki.openstreetmap.org/wiki/PMAPSP_Import Eu comecei a fazer um script no QGIS para gerar as linhas de endereços a partir do GEOLOG. Quando tivermos isso, poderemos criar tarefas no Task Manager do HOT para ir inserindo as numerações. O processo vai ter que ser meio manual, rua por rua, porque é preciso fazer o alinhamento correto. Para a importação da base de rios seria bom também usar o task manager, mas não sei como poderíamos fragmentar o trabalho. Abraço, Vitor -- Forwarded message -- From: Iana Chan iana.muts...@gmail.com Date: 2014-09-08 10:39 GMT-03:00 Subject: Fwd: e-SIC - Pedido Respondido To: Vitor George vitor.geo...@gmail.com, Stephanie Kim Abe steph.kim@gmail.com, Pamela Bassi pam.ba...@gmail.com Oi, pessoal! Tudo bem? Saiu a resposta do pedido em relação ao crédito da fonte para importar os dados para o OSM! Prezada Iana, é necessário explicitar para o público quais são os dados que possuiram origem na PMSP, bem como sua data de importação. Vitor, conseguimos atender a esse detalhe? Temos mais alguns dias para incluir recurso, é preciso? beijos e boa semana para todos! :) Iana -- Forwarded message -- From: nao-respo...@e-sic.prefeitura.sp.gov.br Date: 2014-09-01 13:49 GMT-03:00 Subject: e-SIC - Pedido Respondido To: iana.muts...@gmail.com Sistema e-SIC Prezado(a) Senhor(a), Seu pedido de informação foi analisado e teve resposta na data 01/09/2014, cujo teor segue descrito abaixo. *Protocolo:* 9219 *Requerente:* Iana Chan *Data de Abertura:* 12/08/2014 *Prazo de atendimento:* 01/09/2014 *Órgão da solicitação:* SMDU - Secretaria Municipal de Desenvolvimento Urbano *Solicitação do requerente:* Olá, fiz um pedido de informação sobre a licença de uso de dados disponíveis no site da prefeitura - o número do protocolo é 8967. Vamos importar estes dados para o site OpenStreetMap, e para isso precisamos de um esclarecimento adicional. Para atender a necessidade de dar os créditos devidos precisamos saber se é suficiente declarar nesta página do OpenStreetMap de que há dados da PMSP: http://wiki.openstreetmap.org/wiki/Attribution Isto é o que o OpenStreetMap pode oferecer em termos de crédito de fonte. Podemos prosseguir com a importação? Obrigada, *Resposta:* Prezada Iana, é necessário explicitar para o público quais são os dados que possuiram origem na PMSP, bem como sua data de importação. Atenciosamente, Weber Sutti Chefe de Gabinete SMDU - Secretaria Municipal de Desenvolvimento Urbano - Prefeitura de São Paulo Edifício Martinelli | Rua São Bento, 405 | 18º andar | Centro | CEP 01011-100 | São Paulo | SP T 3113.7751 | 7752 | F 3113.7758 | www.capital.sp.gov.br | webersu...@prefeitura.sp.gov.br FAZER JUNTOS A SÃO PAULO QUE A GENTE QUER. ESSE É O PLANO. | www.gestaourbana.prefeitura.sp.gov.br Para obter detalhes do pedido de informação registrado, acesso e-SIC pelo link http://e-sic.prefeitura.sp.gov.br e clique na opção do *menu* do sistema “Consultar Pedido“. Atenciosamente -- Iana Chan (11) 988-300-455 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Nutzung der IBGE Mapa de Setores Urbanos beim Mappen in Brasilien
Am 08.09.2014 21:26, schrieb Joao Porto: 2014-09-08 18:45 GMT+02:00 Andreas Schmidt schmidt-postf...@freenet.de: 1. Wie schreibe ich die in Majuskeln geschriebenen Namen richtig ab? Beispielsweise „RUA PERICLES VIEIRA“ wird das in portugiesischer Landessprache zu „Rua Pericles Vieira“ oder „Rua pericles Vieira“ oder „Rua pericles vieira“ oder gar zu „rua pericles vieira“? Rua Pericles Vieira wäre hier Richtig. 2. gehe ich recht in der Annahme, dass „RUA SEM DENOMINACAO“ bedeutet, dass die Straßen keinen Namen hat? Genau, die Strasse hat wenigstens keinen offiziellen Name. Wie sollte man es handhaben, diesen „Namen“ ins Namefeld in JOSM eintragen oder den Namen leer lassen? Bisher hat man meinstens das Feld leer gelassen. Ich glaube, das macht auch am meinsten Sinn. plus: noname=yes Auf deutsch noch nicht, aber auf Brasilianischem Portugiesisch gibt es auch die entsprechende Wikiseite [1] Hilft den Mapper_innen und der QA-Software. Falls jemand meine Fragen auf portugiesisch übersetzen kann, würde ich das gerne nehmen und mir einen lokale Mailingliste suchen. Man kann wie vom anderen Mapper vorgeschlägt auf jedem Fall bei unserem Talk-br auf Englisch schreiben, ja sogar auf Deutsch. Sie sind da willkommen und ich persönlich bin nur dankbar für jede Unterstützung, OSM in Brasilien voranzubrigen. +1, wenigstens versuchen, da finden sich bestimmt Moderator_innen, die gerne falls nötig auch übersetzen bzw entstehen persönlich Email Kontakte. Ciao fly [1] https://wiki.openstreetmap.org/wiki/Key:noname ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Mapnik-Stil in Carto-CSS
On Saturday 06 September 2014, Frederik Ramm wrote: [...] Trotz aller dieser Einschränkungen sieht dieser Carto-Stil unserem deutschen Mapnik-Stil schon sehr ähnlich, und wenn es uns gemeinsam gelingt, dem ganzen noch den letzten Schliff zu geben, dann könnten wir vielleicht auch beim deutschen Stil auf Carto umstellen. Ich hab das gerade mal angeschaut und finde auch, dass das eigentlich schon recht gut aussieht. Allerdings lässt sich das derzeit nicht so ohne weiteres in einer Testumgebung parallel zum internationalen Stil bearbeiten. Wäre eigentlich schön, wenn das möglich wäre. Grundsätzlich würde es die zukünftige Synchronisation mit Änderungen im internationalen Stil vermutlich vereinfachen, wenn man dort umfassender die Farben als Variablen definiert so dass der angepasste Stil die nur an einer Stelle ändern muss. Das @gwater-color ist in diesem Zusammenhang eigentlich eher kontraproduktiv. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung der IBGE Mapa de Setores Urbanos beim Mappen in Brasilien
Danke; und ich wollte nur kurz durchsagen, dass ich auf talk-br angekommen bin. Und kurz allgemein meine Auffassung zum Mappen in weit entfernten Gebieten: Wenn der Unterschied so aussieht, wie z.B. hier http://abload.de/img/unbenanntxbj6d.png dann finde ich die neue Version selbst dann besser, falls einmal die Großschreibung falsch sein sollte. Vorher gab es die Ortsstraße in OSM nicht, ebenso wenig wie die Kirche und den Fluss. Nun ist die Rua Pericles Vieira vorhanden und sollte jemand den Namen anders schreiben wollen, kann er es ja verbessern. Grüße Andreas Am 09.09.2014 um 19:11 schrieb fly: Am 08.09.2014 21:26, schrieb Joao Porto: 2014-09-08 18:45 GMT+02:00 Andreas Schmidt schmidt-postf...@freenet.de: 1. Wie schreibe ich die in Majuskeln geschriebenen Namen richtig ab? Beispielsweise „RUA PERICLES VIEIRA“ wird das in portugiesischer Landessprache zu „Rua Pericles Vieira“ oder „Rua pericles Vieira“ oder „Rua pericles vieira“ oder gar zu „rua pericles vieira“? Rua Pericles Vieira wäre hier Richtig. 2. gehe ich recht in der Annahme, dass „RUA SEM DENOMINACAO“ bedeutet, dass die Straßen keinen Namen hat? Genau, die Strasse hat wenigstens keinen offiziellen Name. Wie sollte man es handhaben, diesen „Namen“ ins Namefeld in JOSM eintragen oder den Namen leer lassen? Bisher hat man meinstens das Feld leer gelassen. Ich glaube, das macht auch am meinsten Sinn. plus: noname=yes Auf deutsch noch nicht, aber auf Brasilianischem Portugiesisch gibt es auch die entsprechende Wikiseite [1] Hilft den Mapper_innen und der QA-Software. Falls jemand meine Fragen auf portugiesisch übersetzen kann, würde ich das gerne nehmen und mir einen lokale Mailingliste suchen. Man kann wie vom anderen Mapper vorgeschlägt auf jedem Fall bei unserem Talk-br auf Englisch schreiben, ja sogar auf Deutsch. Sie sind da willkommen und ich persönlich bin nur dankbar für jede Unterstützung, OSM in Brasilien voranzubrigen. +1, wenigstens versuchen, da finden sich bestimmt Moderator_innen, die gerne falls nötig auch übersetzen bzw entstehen persönlich Email Kontakte. Ciao fly [1] https://wiki.openstreetmap.org/wiki/Key:noname ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] dati liberi sull'infomobilità a Bari
Buongiorno Simone, prendo spunto da questo tuo contributo per sottolineare che stiamo provando a seguire un approccio di progettazione partecipata, quindi la domanda che giriamo noi a questa comunità è: qual è la licenza secondo voi più opportuna da utilizzare, e perché ? Così sulla base degli input ricevuti, l'AMTAB potrà scegliere per il meglio. Massimo 2014-09-08 19:02 GMT+02:00 girarsi_liste liste.gira...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Certo, tutto bello, ma la licenza dei dati qual'è? - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlQN4UIACgkQoVS0hKoD3PM7wgD/eBOVqpKgeMsp3pOFv0bSnuxj ZHK4BlseFwzJGPD+CJABAIGWzLaF0iLcBBZP4SRPCpjsXlrT3MctyIEOoR/DaUhT =9wZ/ -END PGP SIGNATURE- ___ 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] MISE su TANTO
Ciao, ho aggiornato le pagine, mettendo una indicazione nella home su come funziona. Ho cambiato il plugin della localizzazione, usando quello di Stefano Cudini, adesso se si attiva il gps la macchinina va a far benzina anche sulla mappa. Altro giochino per OSMit sarà iniziare a pensare l'incrocio dei dati con OSM? Ciao, Stefano Il giorno 26 agosto 2014 22:57, Any File anysomef...@gmail.com ha scritto: 2014-08-26 11:15 GMT+02:00 sabas88 saba...@gmail.com: Forse non è chiaro perché non l'ho scritto come funziona l'interrogazione delle pagine.. Grazie per la spiegazione. Il distributore più conveniente è a Città Studi http://toolserver.openstreetmap.it/carburantiMiSE/cheap.html#15/45.4729/9.2281 Ce ne è uno dalle parti di piazzale Segesta (Milano) che riporta un prezzo talmene basso da essere assurdo. benzina 0.250, gasolio 0.250 Ciao AnyFile ___ 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] dati liberi sull'infomobilità a Bari
2014-09-09 12:04 GMT+02:00 Massimo Zotti massimo.zo...@gmail.com: Buongiorno Simone, prendo spunto da questo tuo contributo per sottolineare che stiamo provando a seguire un approccio di progettazione partecipata, quindi la domanda che giriamo noi a questa comunità è: qual è la licenza secondo voi più opportuna da utilizzare, e perché ? Secondo me qualsiasi compatibile con OSM. Dipende l'AMTAB quanto controllo vuole avere sui dati. A me piace abbastanza la ODbL perchè fa si che chi utilizza i dati non se ne può appropriare del tutto e deve rilasciare con la stessa licenza in caso di miglioramento. Così sulla base degli input ricevuti, l'AMTAB potrà scegliere per il meglio. Massimo -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-gb-thenorth] ?
Oh, I was considering requesting a North East mailing list and then found this one already exists (I was subscribed too). I might encourage people to join so events can be announced through the list. I'm also looking to organise event(s) in Durham or Sunderland in the future. We could do with some increased activity, addresses show just one aspect that is lacking. https://www.flickr.com/photos/sk53_osm/15108130686/in/photostream/ Gregory (LivingWithDragons). P.S. Apologies to Tim moderating the list, I struggled to remember which of my e-mail addresses I had registered with. On 7 April 2012 14:47, Graham Heyes grahamhe...@hotmail.com wrote: Hello Is anyone else on this mailing list besides me prepared to keep this going? Graham ___ Talk-gb-thenorth mailing list Talk-gb-thenorth@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-thenorth -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ Talk-gb-thenorth mailing list Talk-gb-thenorth@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-thenorth
Re: [Talk-es] Estado del arte sobre la detección de señales en OSM
Entiendo que Scout no se ha planteado compartir esos datos con OSM ¿no? De momento estoy probando a subir fotografías a Mapillary [1] por su licencia, facilidad de uso y posible integración en ID Editor [2] o JOSM, y con vista a que en un futuro esas imágenes sirvan de corpus para el uso en OpenStreetMap de algún algoritmo de visión artificial. [1] https://wiki.openstreetmap.org/wiki/Mapillary [2] http://blog.mapillary.com/news,/update/2014/08/19/id.html Un saludo. Emilio Gómez El 3 de septiembre de 2014, 21:31, k1wi k1wi...@gmail.com escribió: La aplicación skobbler va a añadir en su próxima versión el Modo Cámara que reconoce señales de límite de velocidad. Los datos se utilizan para avisar al usuario si se pasa del límite. https://itunes.apple.com/es/app/gps-navegacion-by-scout-navegador/id467318607?mt=8 ___ 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
[Talk-cat] Nota al mapa /SPAM
Hola , M'acabo d'adonar d'aquesta nota d'OpenStreetMap i no se com tractar-la ja que sembla SPAM pero sembla que hi pot haver informacio incompleta d'un negoci. Que en farieu vosaltres? La nota es aquesta: https://www.openstreetmap.org/note/133552#map=17/41.81449/3.05136layers=N Salutacions ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cat] Nota al mapa /SPAM
Amb una mica de sorna i bon rotllo jo recomano explicar-li la situació, explicar-li com pot completar el node, i sobretot treure tot allò que sigui spam. Salut i mapes yopaseopor 2014-09-09 20:35 GMT+02:00 Xavier Barnada xbarn...@gmail.com: Hola , M'acabo d'adonar d'aquesta nota d'OpenStreetMap i no se com tractar-la ja que sembla SPAM pero sembla que hi pot haver informacio incompleta d'un negoci. Que en farieu vosaltres? La nota es aquesta: https://www.openstreetmap.org/note/133552#map=17/41.81449/3.05136layers=N Salutacions ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-cz] Odstávka LPIS
Ahoj, kouknul jsem na ten heapdump v Eclipse memory analyzer. Problem je, ze JTree, ktera zobrazuje seznam provedenych prikazu v JOSM je prilis velka - priblizne 16k sirka i vyska. Takze kdyz zkousi udelat buffer na vykresleni, tak ma 16k*16k*4=1GB (a to jenom pro vykresleni jednoho radku) + pamet v GTK, kterou v dumpu neuvidim. Netusim, proc je to tak velke, ale zkusil bych ten dialog se seznamem prikazu schovat a zkontrolovat konfiguraci, jestli se tam nejakym omylem nedostali nesmyslne rozmery. -- Jirka 2014-09-09 0:59 GMT+02:00 Martin Švec - OSM o...@maatts.cz: Ahoj, (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela javapid.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. Heapdump je k dispozici zde: http://uloz.to/xKexoVkr/java-pid9395-hprof-bz2 JOSM verze 7480 s -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar josm-tested.jar java version 1.8.0_11 Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) Koukal jsem do dumpu přes JVisualVM ale žádný jasný leak nevidím. Total bytes: 89 251 549 taky rozhodně neodpovídá tomu, co reálně sežral josm proces. Pořád ve mě roste podezření, že to žere něco mimo VM Javy, například GTK. Mám 6 GB RAM + 4 GB swapu a byl problém vůbec ten dump vyrobit. Při -Xmx2000m a vyšších si vzal josm proces přes 8 GB RAM a sejmul ho OOM killer, než stihl něco uložit. Stack při OutOfMemoryErroru je pokaždé stejný: - java.lang.OutOfMemoryError: Java heap space Dumping heap to /tmp/java_pid9395.hprof ... Heap dump file created [103911020 bytes in 1,262 secs] CHYBA: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space at java.awt.image.DataBufferInt.init(DataBufferInt.java:75) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:589) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:580) at com.sun.java.swing.plaf.gtk.GTKPainter.paintTreeCellBackground(GTKPainter.java:1181) at javax.swing.plaf.synth.SynthTreeUI.paintRow(SynthTreeUI.java:554) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:359) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:271) at javax.swing.JComponent.paintComponent(JComponent.java:777) at javax.swing.JComponent.paint(JComponent.java:1053) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JViewport.paint(JViewport.java:744) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290) at javax.swing.RepaintManager.paint(RepaintManager.java:1252) at javax.swing.JComponent._paintImmediately(JComponent.java:5165) at javax.swing.JComponent.paintImmediately(JComponent.java:4976) at javax.swing.RepaintManager$3.run(RepaintManager.java:811) at javax.swing.RepaintManager$3.run(RepaintManager.java:794) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Přesně tak, budu tedy lesy v relacích upravovat ručně. Jen mne ještě zarazilo, že JOSM nehlásil žádná varování ohledně překřížených polygonů Dne 9. září 2014 7:43 Marián Kyral mky...@email.cz napsal(a): Jak nenahrazuje? Jako že Tracer ten les nechá na pokoji a nepřipojí jej k tomu natrasovanému poli? No to bude tím, že to je relace a na ty zatím raději nešahám. Možná to časem dopíši. Ale teď si to budeš muset udělat ručně ;-) Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 8. 9. 2014 21:50:00 Předmět: Re: [Talk-cz] Odstávka LPIS tak při zkoušení upraveného traceru jsem zjisti že tracer nenahrazuje překrývající se lesy viz např pole s id lpis 977 nebo 9783761 Pražák Dne 8. září 2014 21:19 Marián Kyral mky...@email.cz napsal(a): Dne 8.9.2014 14:58, Marián Kyral napsal(a): (4) Šlo by udělat, aby při stisknuté klávese Ctrl se vynechala funkce ořezu a navázání na cizí polygony? Bylo by to fajn u LPISu i RUIANu. Někdy je rychlejší ručně napojit okolí na čistý polygon, než zkoumat a opravovat následky automatiky. LPIS viz výše. RUIAN zase typicky vykusuje zářezy do sousedících budov co nejsou v RUIANu, nakreslených nepřesně podle KM. Takže musím likvidovat ocásek vyrobený v místě průniku, přitom by stačilo jen ručně posunout uzel sousední budovy kam patří. Určitě. V tom původním traceru se modifikátory používaly. Já to většinou dělám tak, že dám zpět, bod posunu a znova to natracuji. Ale musím si toho všimnout. Já přilehlé non-RUIAN budovy preventivně posouvám pryč z dosahu traceru, pokud předem tuším problémy ;-) Ten modifikátor by se hodil. OK. To by mělo být jednoduché. ;-) Tak hotovo. Bohužel nový způsob distribuce aktualizací momentálně nefunguje [1]. Tak tady je prozatímní odkaz: http://osm.kyralovi.cz/bin/Tracer-testing.jar Bacha: změnil jsem název na Tracer-testing. Doporučuji smazat starý Tracer.jar v .josm/plugins adresáři. A pak je potřeba v konfiguraci znova povolit plugin Tracer-testing. Doufám, že se problém brzo vyřeší a pak se bude tracer aktualizovat sám, skrz oficiální kanál. A skončí lovení aktuální verze pluginu v hloubi konference. Někteří si to neužívají a mně se to taky moc nelíbí. [1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap.josm.devel/5934 Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Tracer - změna distribuce nových verzí
Ahoj, protože se v tom už sám ztrácím a původní plán nahradit co nejdříve Tracer aktualizovanou verzí nějak selhává = furt to nefunguje jak by mělo, rozhodl jsem distribuovat testovací verzi Traceru jako externí modul. To znamená, že když si teď v JOSM stáhnete seznam pluginů, najdete tam Tracer, Tracer-testing a Tracer2. Stačí odškrknout Tracer a Tracer2 a zatrhnout Tracer-testing. Tak se nainstaluje nejnovější verze a všechny následující aktualizace se pak budou stahovat automaticky. No není to super? :-D Akorát jsem to mohl udělat dříve. Tímto děkuji Psychonmannovi za nakopnutí. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
No ony ty validace nejsou dokonalé. A landuse je něco jiného než building. Ale třeba když mám multipolygon louky, kde uprostřed je nějaké políčko se zeleninou (landuse=meadow a landuse=farmland), tak se mu to nezdá. Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 9. 9. 2014 9:34:09 Předmět: Re: [Talk-cz] Odstávka LPIS Přesně tak, budu tedy lesy v relacích upravovat ručně. Jen mne ještě zarazilo, že JOSM nehlásil žádná varování ohledně překřížených polygonů Dne 9. září 2014 7:43 Marián Kyral mky...@email.cz(mailto:mky...@email.cz) napsal(a): Jak nenahrazuje? Jako že Tracer ten les nechá na pokoji a nepřipojí jej k tomu natrasovanému poli? No to bude tím, že to je relace a na ty zatím raději nešahám. Možná to časem dopíši. Ale teď si to budeš muset udělat ručně ;-) Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz(mailto:zpra...@seznam.cz) Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org (mailto:talk-cz@openstreetmap.org) Datum: 8. 9. 2014 21:50:00 Předmět: Re: [Talk-cz] Odstávka LPIS tak při zkoušení upraveného traceru jsem zjisti že tracer nenahrazuje překrývající se lesy viz např pole s id lpis 977 nebo 9783761 Pražák Dne 8. září 2014 21:19 Marián Kyral mky...@email.cz(mailto:mky...@email.cz) napsal(a): Dne 8.9.2014 14:58, Marián Kyral napsal(a): (4) Šlo by udělat, aby při stisknuté klávese Ctrl se vynechala funkce ořezu a navázání na cizí polygony? Bylo by to fajn u LPISu i RUIANu. Někdy je rychlejší ručně napojit okolí na čistý polygon, než zkoumat a opravovat následky automatiky. LPIS viz výše. RUIAN zase typicky vykusuje zářezy do sousedících budov co nejsou v RUIANu, nakreslených nepřesně podle KM. Takže musím likvidovat ocásek vyrobený v místě průniku, přitom by stačilo jen ručně posunout uzel sousední budovy kam patří. Určitě. V tom původním traceru se modifikátory používaly. Já to většinou dělám tak, že dám zpět, bod posunu a znova to natracuji. Ale musím si toho všimnout. Já přilehlé non-RUIAN budovy preventivně posouvám pryč z dosahu traceru, pokud předem tuším problémy ;-) Ten modifikátor by se hodil. OK. To by mělo být jednoduché. ;-) Tak hotovo. Bohužel nový způsob distribuce aktualizací momentálně nefunguje [1]. Tak tady je prozatímní odkaz: http://osm.kyralovi.cz/bin/Tracer- testing.jar(http://osm.kyralovi.cz/bin/Tracer-testing.jar) Bacha: změnil jsem název na Tracer-testing. Doporučuji smazat starý Tracer. jar v .josm/plugins adresáři. A pak je potřeba v konfiguraci znova povolit plugin Tracer-testing. Doufám, že se problém brzo vyřeší a pak se bude tracer aktualizovat sám, skrz oficiální kanál. A skončí lovení aktuální verze pluginu v hloubi konference. Někteří si to neužívají a mně se to taky moc nelíbí. [1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap.josm.devel/5934 (http://permalink.gmane.org/gmane.comp.gis.openstreetmap.josm.devel/5934) Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org) https://lists.openstreetmap.org/listinfo/talk-cz (https://lists.openstreetmap.org/listinfo/talk-cz) ___ Talk-cz mailing list Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org) https://lists.openstreetmap.org/listinfo/talk-cz (https://lists.openstreetmap.org/listinfo/talk-cz) ___ Talk-cz mailing list Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org) https://lists.openstreetmap.org/listinfo/talk-cz (https://lists.openstreetmap.org/listinfo/talk-cz) ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Ahoj, díky za průzkum, zkusím se od toho odpíchnout dál. Martin Dne 9.9.2014 8:08, Jiri Klement napsal(a): Ahoj, kouknul jsem na ten heapdump v Eclipse memory analyzer. Problem je, ze JTree, ktera zobrazuje seznam provedenych prikazu v JOSM je prilis velka - priblizne 16k sirka i vyska. Takze kdyz zkousi udelat buffer na vykresleni, tak ma 16k*16k*4=1GB (a to jenom pro vykresleni jednoho radku) + pamet v GTK, kterou v dumpu neuvidim. Netusim, proc je to tak velke, ale zkusil bych ten dialog se seznamem prikazu schovat a zkontrolovat konfiguraci, jestli se tam nejakym omylem nedostali nesmyslne rozmery. -- Jirka 2014-09-09 0:59 GMT+02:00 Martin Švec - OSM o...@maatts.cz: Ahoj, (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela javapid.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. Heapdump je k dispozici zde: http://uloz.to/xKexoVkr/java-pid9395-hprof-bz2 JOSM verze 7480 s -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar josm-tested.jar java version 1.8.0_11 Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) Koukal jsem do dumpu přes JVisualVM ale žádný jasný leak nevidím. Total bytes: 89 251 549 taky rozhodně neodpovídá tomu, co reálně sežral josm proces. Pořád ve mě roste podezření, že to žere něco mimo VM Javy, například GTK. Mám 6 GB RAM + 4 GB swapu a byl problém vůbec ten dump vyrobit. Při -Xmx2000m a vyšších si vzal josm proces přes 8 GB RAM a sejmul ho OOM killer, než stihl něco uložit. Stack při OutOfMemoryErroru je pokaždé stejný: - java.lang.OutOfMemoryError: Java heap space Dumping heap to /tmp/java_pid9395.hprof ... Heap dump file created [103911020 bytes in 1,262 secs] CHYBA: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space at java.awt.image.DataBufferInt.init(DataBufferInt.java:75) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:589) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:580) at com.sun.java.swing.plaf.gtk.GTKPainter.paintTreeCellBackground(GTKPainter.java:1181) at javax.swing.plaf.synth.SynthTreeUI.paintRow(SynthTreeUI.java:554) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:359) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:271) at javax.swing.JComponent.paintComponent(JComponent.java:777) at javax.swing.JComponent.paint(JComponent.java:1053) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JViewport.paint(JViewport.java:744) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290) at javax.swing.RepaintManager.paint(RepaintManager.java:1252) at javax.swing.JComponent._paintImmediately(JComponent.java:5165) at javax.swing.JComponent.paintImmediately(JComponent.java:4976) at javax.swing.RepaintManager$3.run(RepaintManager.java:811) at javax.swing.RepaintManager$3.run(RepaintManager.java:794) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - změna distribuce nových verzí
Díky Mariane ! Super to je, ale prosil bych nekomolit jméno. Zažil jsem dost zkomolenin, ale Psychonmann už je dost brutální :) Díky Dne 9. září 2014 9:46 Marián Kyral mky...@email.cz napsal(a): Ahoj, protože se v tom už sám ztrácím a původní plán nahradit co nejdříve Tracer aktualizovanou verzí nějak selhává = furt to nefunguje jak by mělo, rozhodl jsem distribuovat testovací verzi Traceru jako externí modul. To znamená, že když si teď v JOSM stáhnete seznam pluginů, najdete tam Tracer, Tracer-testing a Tracer2. Stačí odškrknout Tracer a Tracer2 a zatrhnout Tracer-testing. Tak se nainstaluje nejnovější verze a všechny následující aktualizace se pak budou stahovat automaticky. No není to super? :-D Akorát jsem to mohl udělat dříve. Tímto děkuji Psychonmannovi za nakopnutí. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - změna distribuce nových verzí
A do zadnice. Já se tak soustředil na počet těch m a n, že mi ten začátek utekl. Já myslel, že to je přezdívka a ona je to zkratka jména :-/ Promiň Marián -- Původní zpráva -- Od: Petr Schönmann pschonm...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 9. 9. 2014 17:02:18 Předmět: Re: [Talk-cz] Tracer - změna distribuce nových verzí Díky Mariane ! Super to je, ale prosil bych nekomolit jméno. Zažil jsem dost zkomolenin, ale Psychonmann už je dost brutální :) Díky Dne 9. září 2014 9:46 Marián Kyral mky...@email.cz napsal(a): Ahoj, protože se v tom už sám ztrácím a původní plán nahradit co nejdříve Tracer aktualizovanou verzí nějak selhává = furt to nefunguje jak by mělo, rozhodl jsem distribuovat testovací verzi Traceru jako externí modul. To znamená, že když si teď v JOSM stáhnete seznam pluginů, najdete tam Tracer, Tracer-testing a Tracer2. Stačí odškrknout Tracer a Tracer2 a zatrhnout Tracer-testing. Tak se nainstaluje nejnovější verze a všechny následující aktualizace se pak budou stahovat automaticky. No není to super? :-D Akorát jsem to mohl udělat dříve. Tímto děkuji Psychonmannovi za nakopnutí. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - změna distribuce nových verzí
Tak zdá se, že nová verze mnohem častěji generuje výjimku: . NullPointerException v SynthTreeUI.java :-( Dá se to ignorovat, ale vadí mi to. A nevím co s tím. CHYBA: java.lang.NullPointerException java.lang.NullPointerException at javax.swing.plaf.synth.SynthTreeUI.paintExpandControl (SynthTreeUI.java:600) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:417) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:271) at javax.swing.JComponent.paintComponent(JComponent.java:769) at javax.swing.JComponent.paint(JComponent.java:1045) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210) at javax.swing.BufferStrategyPaintManager.paint (BufferStrategyPaintManager.java:295) at javax.swing.RepaintManager.paint(RepaintManager.java:1249) at javax.swing.JComponent._paintImmediately(JComponent.java:5158) at javax.swing.JComponent.paintImmediately(JComponent.java:4969) at javax.swing.RepaintManager$3.run(RepaintManager.java:808) at javax.swing.RepaintManager$3.run(RepaintManager.java:796) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege (ProtectionDomain.java:76) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java: 796) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java: 769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager. java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager. java:1677) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege (ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:703) at java.awt.EventDispatchThread.pumpOneEventForFilters (EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:161) at java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:154) at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:182) at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:221) at java.security.AccessController.doPrivileged(Native Method) at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:219) at java.awt.Dialog.show(Dialog.java:1082) at java.awt.Component.show(Component.java:1651) at java.awt.Component.setVisible(Component.java:1603) at java.awt.Window.setVisible(Window.java:1014) at java.awt.Dialog.setVisible(Dialog.java:1005) at org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4. run(PleaseWaitProgressMonitor.java:172) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege (ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:703) at java.awt.EventDispatchThread.pumpOneEventForFilters (EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:161) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 146) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 138) at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) -- Původní zpráva -- Od: Petr Schönmann pschonm...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 9. 9. 2014 17:02:18 Předmět: Re: [Talk-cz] Tracer - změna distribuce nových verzí Díky Mariane ! Super to je, ale prosil bych nekomolit jméno. Zažil jsem dost zkomolenin, ale Psychonmann už je dost brutální :) Díky Dne 9. září 2014 9:46 Marián Kyral mky...@email.cz napsal(a): Ahoj, protože se v tom už sám ztrácím a původní plán nahradit co nejdříve Tracer aktualizovanou verzí nějak selhává = furt to nefunguje jak by mělo, rozhodl jsem distribuovat testovací verzi Traceru jako externí modul. To znamená, že když si teď v JOSM stáhnete
[OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les photos aériennes (orthophotos ?) de Belfort
Un premier contact à la base a sûrement plus de chance de faire avancer le sujet. Les élus sont rarement au courant de ces détails, il faut que ça redescende et il y a plein d'étages où ça risque de coincer (manque de temps, affirmation de son pouvoir de dire NON, etc) Le 8 septembre 2014 20:29, Muselaar musel...@ouvaton.org a écrit : Il faut que je me rende sur place, à la mairie, paraît-il qu'il y a un service cartographique, et qu'ils sont très gentils. Ça permettrait peut-être d'en savoir plus long, plutôt que d'adresser la demande directement au maire, avec un succès tout à fait aléatoire. Il peut tout aussi bien refuser tout net pour montrer que c'est lui qui est aux commandes, que d'accepter tout net pour montrer qu'il a de la largesse d'esprit... Après une alternance politique, tout est toujours possible. Le 08/09/2014 16:15, Christian Quest a écrit : Ce n'est pas toujours aussi simple... Dans le cas du CG93, le CG a acheté une ortho avec certains droits d'usages, mais pas ceux permettant à un tiers (OSM) de l'exploiter pour créer des données. C'est donc le producteur de l'ortho (Aérodata) qui a aussi dit oui pour qu'on puisse l'utiliser. On attend aussi toujours une ouverture à la contribution OSM sur l'ortho de l'IGN... Le 8 septembre 2014 16:05, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Qui est le propriétaire de cette photo satellite : la ville de Belfort ou la Communauté d'Agglomération Belfortaine ? Toutes les communes de l'agglo n'utilisent pas cette photo sur leur site... Quel que soit, l'organisme qui l'a financé, il sera probablement réticent à ce que quelqu'un l'utilise de façon gratuite. La clé sera donc de bien expliquer ce qu'est OSM et à quelles fins serait utilisée cette photo. S'inspirer de l'argumentaire pour le CG93, voire laisser Christian lui-même faire la demande. PY, très enthousiaste à l'idée de pouvoir exploiter cette photo Le 7 septembre 2014 01:40, Muselaar musel...@ouvaton.org a écrit : Bonsoir, Belfort vient de mettre en ligne une nouvelle version de sa photo aérienne, intéressante à plus d'un titre. Non seulement elle est récente (j'estime qu'elle date de l'automne 2013, c'est à dire après les travaux de réorganisation du réseau de bus), mais en plus elle couvre maintenant toute l'agglomération. Sa définition est incomparable par rapport à Bing. http://applications.mairie-belfort.fr/plan_ville_belfort/ Seule question, comment l'utiliser dans JOSM ? À qui faut-il demander l'autorisation, que faut-il demander exactement, comment mettre en place l'incorporation à JOSM ? Beaucoup de questions dont un certain nombre ne sont peut-être pas à ma portée. Muselaar ___ 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 -- Christian Quest - OpenStreetMap France ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
Bonjour, (sur JOSM) Si tu éclates un way appartenant à une relation, les deux segments créés sont automatiquement ajoutés à la relation. Dans ton cas, c'est ce que tu veux, donc ça te simplifie la tâche. (je ne sais pas comment fonctionnent les autres éditeurs, sûrement de la même façon) PY Le 9 septembre 2014 08:10, Eric Debeau eric.deb...@gmail.com a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ 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] AssociatedStreet avec des voies à plusieurs segments
Quand on coupe en deux un way membre d'une relation, l'éditeur (si il est correctement codé) rajoute le nouveau way comme membre de la relation avec le même rôle. Le 9 septembre 2014 08:10, Eric Debeau eric.deb...@gmail.com a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
Bonjour, Si tu éclates une rue déjà présente dans une relation, JOSM appliquera ta modification à la relation concernée (tu auras donc les 2 morceaux dans la relation). Il faut juste, pour cela, que ladite relation ait été préalablement chargée dans JOSM. Francescu Le 9 septembre 2014 08:10, Eric Debeau eric.deb...@gmail.com a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ 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
[OSM-talk-fr] Un nouveau sentier de randonnée dans l'Eure
Bonjour, Vous ne trouvez pas que cela ressemble au fond Mapnik? C'est tout proche de Vernon, Gaël serait dans le coup? http://www.paris-normandie.fr/detail_article/articles/1384135/sur-le-chemin-du-vexin Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Lancement campagne de financement OSM-FR
Hier soir, lors de notre fête des 10 ans d'OSM au NUMA nous avons lancé notre première collecte pour faire évoluer notre infrastructure matérielle (achat de SSD, achat d'un nouveau serveur, upgrade en RAM, etc). Vous le savez, OpenStreetMap France fournit grâce à une dizaine de serveurs des services nombreux et variés aux contributeurs (osmose, umap, tuiles, etc). Ces serveurs ont besoin d'évoluer au fur et à mesure que le projet et la communauté grandissent. C'est le but de cet appel aux dons. Pour participer: http://www.helloasso.com/associations/openstreetmap-france/collectes/financement-infra-2014 Merci d'avance à tous ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Organisation 10 ans OSM
Bonjour Je ne pouvais malheureusement pas venir hier soir pour l'anniversaire des dix ans d'OSM. http://www.openstreetmap.fr/10ans Des interventions ont-elles été enregistrées? Merci. PS : quelle est le canal le plus actif : la mailing list FR d'OSM via Nabble (http://gis.19327.n5.nabble.com/France-f5380434.html), ou le forum web (http://forum.openstreetmap.fr)? -- View this message in context: http://gis.19327.n5.nabble.com/Organisation-10-ans-OSM-tp5816351p5816981.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] Organisation 10 ans OSM
En principe oui, je vais passer au NUMA pour récupérer les fichiers... Le plus actif (hardcore) est la mailing list talk-fr Le forum est plus calme et plus destiné à l'accompagnement des nouveaux contributeurs qui seraient rapidement rebutés par le rythme soutenu de talk-fr Le 9 septembre 2014 10:45, Shohreh codecompl...@free.fr a écrit : Bonjour Je ne pouvais malheureusement pas venir hier soir pour l'anniversaire des dix ans d'OSM. http://www.openstreetmap.fr/10ans Des interventions ont-elles été enregistrées? Merci. PS : quelle est le canal le plus actif : la mailing list FR d'OSM via Nabble (http://gis.19327.n5.nabble.com/France-f5380434.html), ou le forum web (http://forum.openstreetmap.fr)? -- View this message in context: http://gis.19327.n5.nabble.com/Organisation-10-ans-OSM-tp5816351p5816981.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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tile.openstreetmap.fr off ?
Bonjour tile.openstreetmap.fr semble ne plus répondre. Après un temps assez long, je reçois un message: La connexion avec le serveur a été réinitialisée pendant le chargement de la page. cordialement claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
Merci pour les réponses rapides. J'utilise JOSM, mais je n'ai pas encore beaucoup manipulé les relations. Je suis toujours agréablement surpris par la puissance de cet outil. Eric Le 9 sept. 2014 08:35, Francescu GAROBY windu...@gmail.com a écrit : Bonjour, Si tu éclates une rue déjà présente dans une relation, JOSM appliquera ta modification à la relation concernée (tu auras donc les 2 morceaux dans la relation). Il faut juste, pour cela, que ladite relation ait été préalablement chargée dans JOSM. Francescu Le 9 septembre 2014 08:10, Eric Debeau eric.deb...@gmail.com a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
Bonjour, iD rajoute également les segments aux relations de la way originale, mais il les ajoute à la fin de la relation donc l'ordre se retrouve cassé. Le 09/09/2014 08:10, Eric Debeau a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ 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
[OSM-talk-fr] osm13: serveur farceur...
Sacré farceur osm13, notre serveur de tuiles principal. On lui promet un nouveau SSD, un peu de RAM et hop il en profite pour nous faire comprendre que ça urge ! La base postgresql sent un peu le moisi... recovery mode. Du coup serveur de tuiles HS... Pour les tuiles HOT, j'ai mis en place une redirection vers notre autre serveur (layers), mais pas pour les tuiles FR. N'hésitez pas à relayer l'adresse de la page de collecte... on a pour l'instant un demi SSD... http://www.helloasso.com/associations/openstreetmap-france/collectes/financement-infra-2014 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] AssociatedStreet avec des voies à plusieurs segments
iD ne reproduit pas correctement les rôles non plus. L'ordre brisé est aussi un problème plus grave pour les relations o c'est important et qui ne représentent pas directement une surface mais un itinéraire. Son éditeur de relations est pour l'instant trop mal fichu pour qu'il soit utilisable pour autre chose que taguer quelques POIs et ajouter ou déplacer légèrement des noeuds existants Mais trop régulièrement il saccage les itinéraires bus; et ne parlons pas non plsu de son utilisation pour transformer un carrefour en rond-point: là c'est la cata assurée ! Je trouve dommage d'en avoir fait l'diteur par défaut sur le site principal d'OSM: Potlatch 2 est dix fois mieux mais rien ne vaut JOSM actuellement; le seul outil pour gérer les situations compliquées et faire de la réparation sérieuse, et le seul outil capable de gérer correctement des données à importer et fusionner. Le 9 septembre 2014 15:12, JeanMichel FRANCOIS jeanmichel.franc...@makina-corpus.com a écrit : Bonjour, iD rajoute également les segments aux relations de la way originale, mais il les ajoute à la fin de la relation donc l'ordre se retrouve cassé. Le 09/09/2014 08:10, Eric Debeau a écrit : Bonjour Je démarre la saisie d'adresses avoir avoir 'nettoyé' les noms de rue de ma ville. Je préfère utiliser la solution avec les relations AssociatedStreet, mais j'ai une question pour la gestion de la relation. Quand une voie est représentée par plusieurs segments avec des 'ways' différents, le wiki ( http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street) indique qu'il faut mettre les différents segments avec le role 'street'. Ensuite, comment on gère ensuite les modifications d'une rue que l'on éclate en plusieurs segments plus tard (cause limite vitesse partielle, piste cyclable partielle...) ? Osmose va le détecter ? Merci Eric ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] DKIM Re: bano : besoin d'éclaircissements
Le 7 septembre 2014 00:13, Vincent de Château-Thierry v...@laposte.net a
écrit :
Bonsoir,
Le 05/09/2014 09:36, v...@laposte.net a écrit :
De: Christian Quest cqu...@openstreetmap.fr
Le polygone n'englobe que les adresses, pas la voirie.
Le petit tronçon à l'ouest n'a pas d'adresse proche, c'est donc pour ça
qu'il est en dehors.
En regardant hier soir je n'ai pas compris le pourquoi du problème
initial. On a un bon paquet de 'Grande Rue' rapprochées en base, avec coté
Fantoir des variantes ('GR GRANDE RUE', etc.). Je regarderai à nouveau ce
week-end, il y a possiblement un loup dans le code.
Bon... en re-regardant à l'instant, plus de mauve sur la Grande Rue. Mais
je n'ai touché à rien entre temps. Pierre-Yves, de ton côté ?
vincent
Je constate également une coexistence de bleu et mauve ici :
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.69661/6.18022
Encore une Grande Rue.
Voyons si le fait de le signaler ici fait disparaître le problème.
PY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lancement campagne de financement OSM-FR
Hello, Je me suis permis de faire quelques modifs sur le texte qui n'était pas toujours très clair : Le premier objectif est de compléter les serveurs actuels par des SSD de 1To plus performants. Le premier objectif est de compléter les serveurs actuels avec des SSD de 1To plus performants. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux services. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux outils. Ce serveur sera aussi utile lors des crises humanitaires comme nous avons pu le faire à plusieurs reprises pour héberger des images satellite utilisée afn de gérer la charge supplémentaire que cela représente. Ce serveur sera aussi utile pour gérer la charge supplémentaire lors des crises humanitaires. Il hébergera des images satellites, comme nous avons pu le faire à plusieurs reprises. Afin de vous donner une idée des montants, nous avons indiqué à quoi chaque don correspond approximativement. Afin de vous donner une idée des montants, nous avons indiqué à quoi correspond approximativement chaque don. Stf Le mardi 9 septembre 2014 08:53:12, Christian Quest a écrit : Hier soir, lors de notre fête des 10 ans d'OSM au NUMA nous avons lancé notre première collecte pour faire évoluer notre infrastructure matérielle (achat de SSD, achat d'un nouveau serveur, upgrade en RAM, etc). Vous le savez, OpenStreetMap France fournit grâce à une dizaine de serveurs des services nombreux et variés aux contributeurs (osmose, umap, tuiles, etc). Ces serveurs ont besoin d'évoluer au fur et à mesure que le projet et la communauté grandissent. C'est le but de cet appel aux dons. Pour participer: http://www.helloasso.com/associations/openstreetmap-france/collectes/financement-infra-2014 Merci d'avance à tous ! -- Christian Quest - OpenStreetMap France ___ 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] Lancement campagne de financement OSM-FR
C'est modifié. Merci ! Le 9 septembre 2014 17:14, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Hello, Je me suis permis de faire quelques modifs sur le texte qui n'était pas toujours très clair : Le premier objectif est de compléter les serveurs actuels par des SSD de 1To plus performants. Le premier objectif est de compléter les serveurs actuels avec des SSD de 1To plus performants. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux services. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux outils. Ce serveur sera aussi utile lors des crises humanitaires comme nous avons pu le faire à plusieurs reprises pour héberger des images satellite utilisée afn de gérer la charge supplémentaire que cela représente. Ce serveur sera aussi utile pour gérer la charge supplémentaire lors des crises humanitaires. Il hébergera des images satellites, comme nous avons pu le faire à plusieurs reprises. Afin de vous donner une idée des montants, nous avons indiqué à quoi chaque don correspond approximativement. Afin de vous donner une idée des montants, nous avons indiqué à quoi correspond approximativement chaque don. Stf Le mardi 9 septembre 2014 08:53:12, Christian Quest a écrit : Hier soir, lors de notre fête des 10 ans d'OSM au NUMA nous avons lancé notre première collecte pour faire évoluer notre infrastructure matérielle (achat de SSD, achat d'un nouveau serveur, upgrade en RAM, etc). Vous le savez, OpenStreetMap France fournit grâce à une dizaine de serveurs des services nombreux et variés aux contributeurs (osmose, umap, tuiles, etc). Ces serveurs ont besoin d'évoluer au fur et à mesure que le projet et la communauté grandissent. C'est le but de cet appel aux dons. Pour participer: http://www.helloasso.com/associations/openstreetmap- france/collectes/financement-infra-2014 Merci d'avance à tous ! -- Christian Quest - OpenStreetMap France ___ 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] site web openstreetmap.fr et sa page comment contribuer
Ca ne déchaine pas les foules :-) Je vais bosser sur le sujet lorsque j'aurai un peu de temps. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] site web openstreetmap.fr et sa page comment contribuer
Si si. Je trouve ça vraiment pas mal, pour ne pas dire vachement bien. je propose chevronné pour le level 5. PY 2014-09-09 17:38 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr: Ca ne déchaine pas les foules :-) Je vais bosser sur le sujet lorsque j'aurai un peu de temps. 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] Lancement campagne de financement OSM-FR
Ce soir sur France-Inter... Le téléphone sonne est consacré au crowdfunding... Si vous avez du temps à partir de 19h30, n'hésitez pas à appeler le standard, on ne sait jamais on peut arriver à passer à l'antenne et ça sera le coup de fil à 1 ;) Le 9 septembre 2014 17:23, Christian Quest cqu...@openstreetmap.fr a écrit : C'est modifié. Merci ! Le 9 septembre 2014 17:14, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Hello, Je me suis permis de faire quelques modifs sur le texte qui n'était pas toujours très clair : Le premier objectif est de compléter les serveurs actuels par des SSD de 1To plus performants. Le premier objectif est de compléter les serveurs actuels avec des SSD de 1To plus performants. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux services. Ceci permettra d'offrir des services de meilleure qualité, plus réactifs ainsi que de nouveaux outils. Ce serveur sera aussi utile lors des crises humanitaires comme nous avons pu le faire à plusieurs reprises pour héberger des images satellite utilisée afn de gérer la charge supplémentaire que cela représente. Ce serveur sera aussi utile pour gérer la charge supplémentaire lors des crises humanitaires. Il hébergera des images satellites, comme nous avons pu le faire à plusieurs reprises. Afin de vous donner une idée des montants, nous avons indiqué à quoi chaque don correspond approximativement. Afin de vous donner une idée des montants, nous avons indiqué à quoi correspond approximativement chaque don. Stf Le mardi 9 septembre 2014 08:53:12, Christian Quest a écrit : Hier soir, lors de notre fête des 10 ans d'OSM au NUMA nous avons lancé notre première collecte pour faire évoluer notre infrastructure matérielle (achat de SSD, achat d'un nouveau serveur, upgrade en RAM, etc). Vous le savez, OpenStreetMap France fournit grâce à une dizaine de serveurs des services nombreux et variés aux contributeurs (osmose, umap, tuiles, etc). Ces serveurs ont besoin d'évoluer au fur et à mesure que le projet et la communauté grandissent. C'est le but de cet appel aux dons. Pour participer: http://www.helloasso.com/associations/openstreetmap- france/collectes/financement-infra-2014 Merci d'avance à tous ! -- Christian Quest - OpenStreetMap France ___ 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 -- Christian Quest - OpenStreetMap France -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lancement campagne de financement OSM-FR
J'ai oublié celle-ci : Le second est l'achat d'un nouveau serveur nous permettra d'avoir une machine de secours, Le second est l'achat d'un nouveau serveur qui nous permettra d'avoir une machine de secours, ou bien Le second est l'achat d'un nouveau serveur ce qui nous permettra d'avoir une machine de secours, Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] site web openstreetmap.fr et sa page comment contribuer
Idée super intéressante. J'ai démarré ma contribution active à OSM par rapport à mon activité de géo-caching et je connais quelques géocacheurs qui seraient aussi volontaires pour contribuer à OSM. Comme l'indique Christian, partage ta propal sur un pad. Comme ca, on pourra compléter/corriger de manière plus interactive. Pour le niveau 4, actif Pour le niveau 1, je montre à mon club de randos la qualité des cartes osm, les améliorations locales... J'aurais enlevé la partie sur la demande à la mairie et rajouté un niveau : Lobbyiste/militant : je demande/exige à la mairie, com agglo, entités publiques de libérer les données. Un niveau gentil organisateur : j'organise des cartos party, des présentations publiques sur osm Eric 2014-09-09 18:11 GMT+02:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: Si si. Je trouve ça vraiment pas mal, pour ne pas dire vachement bien. je propose chevronné pour le level 5. PY 2014-09-09 17:38 GMT+02:00 Stéphane Péneau stephane.pen...@wanadoo.fr: Ca ne déchaine pas les foules :-) Je vais bosser sur le sujet lorsque j'aurai un peu de temps. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lancement campagne de financement OSM-FR
Le don à OpenStreetMap France ouvre droit à déduction fiscale car il remplit les conditions générales prévues aux articles 200 et 238 bis du code général des impôts. C'est tout récent ça, non ? Le 9 septembre 2014 08:53, Christian Quest cqu...@openstreetmap.fr a écrit : Hier soir, lors de notre fête des 10 ans d'OSM au NUMA nous avons lancé notre première collecte pour faire évoluer notre infrastructure matérielle (achat de SSD, achat d'un nouveau serveur, upgrade en RAM, etc). Vous le savez, OpenStreetMap France fournit grâce à une dizaine de serveurs des services nombreux et variés aux contributeurs (osmose, umap, tuiles, etc). Ces serveurs ont besoin d'évoluer au fur et à mesure que le projet et la communauté grandissent. C'est le but de cet appel aux dons. Pour participer: http://www.helloasso.com/associations/openstreetmap-france/collectes/financement-infra-2014 Merci d'avance à tous ! -- Christian Quest - OpenStreetMap France ___ 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
[OSM-talk-fr] Géocacheurs...
Le 9 septembre 2014 22:44, Eric Debeau eric.deb...@gmail.com a écrit : Idée super intéressante. J'ai démarré ma contribution active à OSM par rapport à mon activité de géo-caching et je connais quelques géocacheurs qui seraient aussi volontaires pour contribuer à OSM. C'est une communauté vers laquelle nous devrions tisser plus de liens. Terrain + GPS + curieux... les ingrédients de base sont là ! Nous serons présent au Mega event à Jabline (77) en octobre... stand + cartopartie. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lancement campagne de financement OSM-FR
Le 10 septembre 2014 00:08, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Le don à OpenStreetMap France ouvre droit à déduction fiscale car il remplit les conditions générales prévues aux articles 200 et 238 bis du code général des impôts. C'est tout récent ça, non ? Non, pas vraiment. Nous répondons aux critères de l'intérêt général. C'est aussi simple que ça. C'est la première fois que nous faisons un appel au dons, c'est surtout ça qui est nouveau. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lancement campagne de financement OSM-FR
Un argument non négligeable ^^ Le 10 septembre 2014 00:15, Christian Quest cqu...@openstreetmap.fr a écrit : Le 10 septembre 2014 00:08, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Le don à OpenStreetMap France ouvre droit à déduction fiscale car il remplit les conditions générales prévues aux articles 200 et 238 bis du code général des impôts. C'est tout récent ça, non ? Non, pas vraiment. Nous répondons aux critères de l'intérêt général. C'est aussi simple que ça. C'est la première fois que nous faisons un appel au dons, c'est surtout ça qui est nouveau. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] Prima Facie Speed Limits
Am Montag, 8. September 2014 schrieb Tod Fitch : How does this sound? +1 Cheers, Martin -- Martin Koppenhoefer (Dipl-Ing. Arch.) Via del Santuario Regina degli Apostoli, 18 00145 Roma |I|I|I|I|I|I|I|I| Italia N41.851, E12.4824 tel1: +39 06.916508070 tel2: +49 30 868708638 mobil: +39 392 3114712 mobil: +49 1577 7793740 m...@koppenhoefer.com http://www.koppenhoefer.com Hinweis: Diese Nachricht wurde manuell erstellt. Wir bemühen uns um fehlerfreie Korrespondenz, dennoch kann es in Ausnahmefällen vorkommen, dass bei der manuellen Übertragung von Informationen in elektronische Medien die übertragenen Informationen Fehler aufweisen. Wir bitten Sie, dies zu entschuldigen. Any views or opinions are solely those of the author and do not necessarily represent those of koppenhoefer.com unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@koppenhoefer.com Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
On 09/08/2014 05:27 PM, Tod Fitch wrote: [...] instead there is a state wide prima facie limit: source:maxspeed=US:CA:residential [...] My state doesn't have such a limit, but my city does. Supposing I started tagging things with source:maxspeed=US:VT:Burlington, would anyone be upset that Burlington and residential are in the same place in the hierarchy? (I'm hoping the answer here is no one cares, the value isn't intended to be machine parsable, and both values are understandable by humans.) --Andrew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
In Europe (at least Germany, Belgium, The Netherlands, UK) people started to add both source:maxspeed=country code:classification and explicit maxspeed tags. Then there is no need for an external DB to lookup the speeds. Although it means that when the speed changes, all roads have to be retagged. regards On Tue, Sep 9, 2014 at 1:00 AM, Tod Fitch t...@fitchdesign.com wrote: California has a 25 MPH rule for school zones while Arizona has (or at least had when I lived there) a 15 MPH school zone limit. It seems that 25 MPH in a residential area is pretty standard but I think states have enough discretion in setting limits that they could vary from one state to the next. So I think the source attribution should allow for differences between states for the same class of road. Thus my suggestion for source:maxspeed=US:CA:residential for tagging in my area. On Sep 8, 2014, at 2:55 PM, Greg Morgan wrote: On Mon, Sep 8, 2014 at 2:27 PM, Tod Fitch t...@fitchdesign.com wrote: Thus far I've only applied the maxspeed tag to roads with a posted speed limit. But here in California most residential roads are not posted, instead there is a state wide prima facie limit: http://www.dmv.ca.gov/pubs/vctop/d11/vc22352.htm I wonder if 15 mph in a school zone and 25 mph in a residential area are some sort of federal standard? The source tag might be useful but not much different than other states. Regards, Greg ___ 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] Prima Facie Speed Limits
On Sep 9, 2014, at 6:10 AM, Andrew Guertin wrote: On 09/08/2014 05:27 PM, Tod Fitch wrote: [...] instead there is a state wide prima facie limit: source:maxspeed=US:CA:residential [...] My state doesn't have such a limit, but my city does. Supposing I started tagging things with source:maxspeed=US:VT:Burlington, would anyone be upset that Burlington and residential are in the same place in the hierarchy? (I'm hoping the answer here is no one cares, the value isn't intended to be machine parsable, and both values are understandable by humans.) I think there are two reasons for the source:maxspeed tag: 1) So the next mapper who touches the maxspeed value knows where it came from. 2) To be able to find all the occurrences of maxspeed that were determined by the source. Something searchable but not necessarily machine parseable should be okay. On Sep 8, 2014, at 10:30 PM, Marc Gemis wrote: In Europe (at least Germany, Belgium, The Netherlands, UK) people started to add both source:maxspeed=country code:classification and explicit maxspeed tags. Then there is no need for an external DB to lookup the speeds. Although it means that when the speed changes, all roads have to be retagged. As long as the source:maxspeed value is unique to the jurisdiction then it is easy to find all the roads that need to be retagged. On Sep 8, 2014, at 3:58 PM, Richard Welty wrote: the default speed limit in NYS for unposted roads is 55mph, irrespective of surface type. other states vary; there's a page in the OSM wiki about it. If I recall correctly, NYS changed their rural highways from 50 MPH to 55 MPH when the nationwide 55 MPH limit came into effect in the early 1970s. So these speeds can definitely change, though usually change is slow. I think that if the value for the source:maxspeed tag uniquely specifies the jurisdiction and is something that is readily understandable by a human then is should be okay. So US:CA:residential and US:VT:Burlington or US:VT:Burlington:residential would meet those requirements. Sounds like the responders to this thread are either unopposed or generally in favor of the concept. I think I'll start tagging this way in my local area. Thanks! Tod ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
I'm of the opinion that wherever the speed limit is just the default for that road class, it should not need to be posted at all. Any data user can then infer limits. Martijn On Mon, Sep 8, 2014 at 3:27 PM, Tod Fitch t...@fitchdesign.com wrote: Thus far I've only applied the maxspeed tag to roads with a posted speed limit. But here in California most residential roads are not posted, instead there is a state wide prima facie limit: http://www.dmv.ca.gov/pubs/vctop/d11/vc22352.htm I am considering tagging the unsigned speed limit on residential roads in my area and am thinking of tagging the authority of the speed with source:maxspeed=US:CA:residential based on an extension of the type of things I see at http://wiki.openstreetmap.org/wiki/Key:source:maxspeed How does this sound? Objections? Is there a better way? Thanks! Tod ___ 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] Prima Facie Speed Limits
One street here in Nashville, TN, went for several years without any speed limit signs along its three-mile length. Then, one day, it suddenly had signs every half-mile or so. I suspect that someone probably argued their way out of a speeding ticket on the grounds that there weren't any posted limits. Tennessee doesn't have any default speed limits that I am aware of, although one can always be cited for reckless driving. On September 9, 2014 10:47:24 AM CDT, Martijn van Exel m...@rtijn.org wrote: I'm of the opinion that wherever the speed limit is just the default for that road class, it should not need to be posted at all. Any data user can then infer limits. Martijn On Mon, Sep 8, 2014 at 3:27 PM, Tod Fitch t...@fitchdesign.com wrote: Thus far I've only applied the maxspeed tag to roads with a posted speed limit. But here in California most residential roads are not posted, instead there is a state wide prima facie limit: http://www.dmv.ca.gov/pubs/vctop/d11/vc22352.htm I am considering tagging the unsigned speed limit on residential roads in my area and am thinking of tagging the authority of the speed with source:maxspeed=US:CA:residential based on an extension of the type of things I see at http://wiki.openstreetmap.org/wiki/Key:source:maxspeed How does this sound? Objections? Is there a better way? Thanks! Tod ___ 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 -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr.___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
I wonder if 15 mph in a school zone and 25 mph in a residential area are some sort of federal standard? The source tag might be useful but not much different than other states. The federal government doesn't have anything to say about speed limits (in states), as the US Constitution leaves such things to the states. An exception is on federal land, such as national parks or BLM land, where specific parts of the US Code regarding speed limits DO apply. This is why you can get a speeding or parking ticket at Yosemite, but you won't deal with California to fight it or pay the fine: Yosemite is not part of California. Surrounded by it, yes. Part of it, no. My GPS (a still-tough Garmin 60 CSx) does an excellent job of calculating Estimated Time of Arrival (ETA) when routing. It does so by assuming speed limits for all road segments in the current route and guesses I'll travel at those speeds. This is done without assigning a speed limit to each and every road segment, instead implementing a simple table lookup (freeway: assume 65 MPH, residential: assume 25 MPH...). This is a highly efficient solution that keeps the data light and the calculation short and simple, so it quickly produces an accurate ETA result. Though I don't find incorrect (or offensive) the suggestion of tagging prima facie limits with the tagging syntax specified, I find speed limit tagging to be most useful where there are posted signs with a specific number. That's just me, though. SteveA California___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
On Sep 9, 2014, at 10:31 AM, stevea wrote: I wonder if 15 mph in a school zone and 25 mph in a residential area are some sort of federal standard? The source tag might be useful but not much different than other states. The federal government doesn't have anything to say about speed limits (in states), as the US Constitution leaves such things to the states. An exception is on federal land, such as national parks or BLM land, where specific parts of the US Code regarding speed limits DO apply. This is why you can get a speeding or parking ticket at Yosemite, but you won't deal with California to fight it or pay the fine: Yosemite is not part of California. Surrounded by it, yes. Part of it, no. My GPS (a still-tough Garmin 60 CSx) does an excellent job of calculating Estimated Time of Arrival (ETA) when routing. It does so by assuming speed limits for all road segments in the current route and guesses I'll travel at those speeds. This is done without assigning a speed limit to each and every road segment, instead implementing a simple table lookup (freeway: assume 65 MPH, residential: assume 25 MPH...). This is a highly efficient solution that keeps the data light and the calculation short and simple, so it quickly produces an accurate ETA result. Though I don't find incorrect (or offensive) the suggestion of tagging prima facie limits with the tagging syntax specified, I find speed limit tagging to be most useful where there are posted signs with a specific number. That's just me, though. SteveA California The DVD map based nav system in my 10 year old car makes the same assumption about speeds based on its three classes of roads. It had wildly incorrect times until I configured it for California speeds. Now it does a reasonable job at estimating travel times on its selected route if I am in California. But typical rural speed freeway speeds vary considerably from state to state and for longer trips the times are still quite a bit off. Assumed values are not as good as actual values. (And my car nav system always tries for the slow way to the southern SF bay are apparently ignoring that CA 152 exists until I actually make the turn on to it from I-5 when it realizes that my way is both shorter and faster than the route it picked, so it has other problems.) A while back I suggested that prima facie speed limits tags be put the boundary area/relation for administrative areas. So the relation for California could specify something like prima_facie:maxspeed:motorway=65 MPH. This would be a simple to implement scheme with relatively few entries in OSM and be easy to update in the rare situation where the law changes. It could also allow for city or county rules to be specified. Routing algorithms could discover the appropriate assumed speeds for any class of road in an area buy looking at the enclosing administrative boundaries and the tags on those boundaries. But that suggestion was met with a pretty cold response by the tagging mail list. Instead a multitude of roads in Europe and elsewhere are being tagged with the prima facie speeds and having a source:maxspeed tag to explain it. My suggestion in this thread will contributed to that so I admit it is not my first choice. Tod ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
There's a functional difference between speed limits and the actual speed driven. For ETA prediction, speed limit data is not all that useful - detailed historical and live speed profiles are. That is not data that is in OSM (or should be). The speed limits are mostly useful for alerting drivers they may be driving too fast. For a system like that to be feasible you will need comprehensive posted speed limit coverage, which OSM currently does not have. Martijn On Tue, Sep 9, 2014 at 12:38 PM, Tod Fitch t...@fitchdesign.com wrote: On Sep 9, 2014, at 10:31 AM, stevea wrote: I wonder if 15 mph in a school zone and 25 mph in a residential area are some sort of federal standard? The source tag might be useful but not much different than other states. The federal government doesn't have anything to say about speed limits (in states), as the US Constitution leaves such things to the states. An exception is on federal land, such as national parks or BLM land, where specific parts of the US Code regarding speed limits DO apply. This is why you can get a speeding or parking ticket at Yosemite, but you won't deal with California to fight it or pay the fine: Yosemite is not part of California. Surrounded by it, yes. Part of it, no. My GPS (a still-tough Garmin 60 CSx) does an excellent job of calculating Estimated Time of Arrival (ETA) when routing. It does so by assuming speed limits for all road segments in the current route and guesses I'll travel at those speeds. This is done without assigning a speed limit to each and every road segment, instead implementing a simple table lookup (freeway: assume 65 MPH, residential: assume 25 MPH...). This is a highly efficient solution that keeps the data light and the calculation short and simple, so it quickly produces an accurate ETA result. Though I don't find incorrect (or offensive) the suggestion of tagging* prima facie* limits with the tagging syntax specified, I find speed limit tagging to be most useful where there are posted signs with a specific number. That's just me, though. SteveA California The DVD map based nav system in my 10 year old car makes the same assumption about speeds based on its three classes of roads. It had wildly incorrect times until I configured it for California speeds. Now it does a reasonable job at estimating travel times on its selected route if I am in California. But typical rural speed freeway speeds vary considerably from state to state and for longer trips the times are still quite a bit off. Assumed values are not as good as actual values. (And my car nav system always tries for the slow way to the southern SF bay are apparently ignoring that CA 152 exists until I actually make the turn on to it from I-5 when it realizes that my way is both shorter and faster than the route it picked, so it has other problems.) A while back I suggested that prima facie speed limits tags be put the boundary area/relation for administrative areas. So the relation for California could specify something like prima_facie:maxspeed:motorway=65 MPH. This would be a simple to implement scheme with relatively few entries in OSM and be easy to update in the rare situation where the law changes. It could also allow for city or county rules to be specified. Routing algorithms could discover the appropriate assumed speeds for any class of road in an area buy looking at the enclosing administrative boundaries and the tags on those boundaries. But that suggestion was met with a pretty cold response by the tagging mail list. Instead a multitude of roads in Europe and elsewhere are being tagged with the prima facie speeds and having a source:maxspeed tag to explain it. My suggestion in this thread will contributed to that so I admit it is not my first choice. Tod ___ 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] Prima Facie Speed Limits
Historical and live speed profiles are pretty much required for trip planning in congested urban areas, but for those of us who drive close to the speed limit and make long trips on relatively uncrowded rural freeways, travel time estimates based on posted (or prima facie) speeds are a good approximation to reality. I travel between northern California and southern Arizona a lot. The distance is about 1,300 kilometers and only a small fraction of that is congested urban freeways (especially if I decide, as I usually do, to avoid Los Angeles). OsmAnd with its knowledge of actual posted speed limits (many entered by me) does a very good job at predicting my arrival time. On Sep 9, 2014, at 11:48 AM, Martijn van Exel wrote: There's a functional difference between speed limits and the actual speed driven. For ETA prediction, speed limit data is not all that useful - detailed historical and live speed profiles are. That is not data that is in OSM (or should be). The speed limits are mostly useful for alerting drivers they may be driving too fast. For a system like that to be feasible you will need comprehensive posted speed limit coverage, which OSM currently does not have. Martijn ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
Agreed - that's a pretty small use case, relatively, though. On Tue, Sep 9, 2014 at 1:38 PM, Tod Fitch t...@fitchdesign.com wrote: Historical and live speed profiles are pretty much required for trip planning in congested urban areas, but for those of us who drive close to the speed limit and make long trips on relatively uncrowded rural freeways, travel time estimates based on posted (or prima facie) speeds are a good approximation to reality. I travel between northern California and southern Arizona a lot. The distance is about 1,300 kilometers and only a small fraction of that is congested urban freeways (especially if I decide, as I usually do, to avoid Los Angeles). OsmAnd with its knowledge of actual posted speed limits (many entered by me) does a very good job at predicting my arrival time. On Sep 9, 2014, at 11:48 AM, Martijn van Exel wrote: There's a functional difference between speed limits and the actual speed driven. For ETA prediction, speed limit data is not all that useful - detailed historical and live speed profiles are. That is not data that is in OSM (or should be). The speed limits are mostly useful for alerting drivers they may be driving too fast. For a system like that to be feasible you will need comprehensive posted speed limit coverage, which OSM currently does not have. Martijn ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
Yes, a pretty small use case at somewhere around 10,000,000 trips per year on I-5 through the central valley of California. Or 9,000,000 trips per year each way on I-8 across the desert to the Arizona border. On your daily commute, you may not need help navigating so much as you want accurate real time information about which routes are moving well compared to others. For me, trip planning and using a navigation device is not for local driving (I mostly use OsmAnd for local driving to help me find errors in OSM data) as much as for getting me to places I don't go on a daily basis. You could say it is a pretty small use case as most people don't drive to or through unfamiliar places everyday, but it is probably the biggest use case for a nav system there is. Cheers, Tod On Sep 9, 2014, at 1:17 PM, Martijn van Exel wrote: Agreed - that's a pretty small use case, relatively, though. On Tue, Sep 9, 2014 at 1:38 PM, Tod Fitch t...@fitchdesign.com wrote: Historical and live speed profiles are pretty much required for trip planning in congested urban areas, but for those of us who drive close to the speed limit and make long trips on relatively uncrowded rural freeways, travel time estimates based on posted (or prima facie) speeds are a good approximation to reality. I travel between northern California and southern Arizona a lot. The distance is about 1,300 kilometers and only a small fraction of that is congested urban freeways (especially if I decide, as I usually do, to avoid Los Angeles). OsmAnd with its knowledge of actual posted speed limits (many entered by me) does a very good job at predicting my arrival time. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prima Facie Speed Limits
Thanks for clarifying, Tod. For ETA the congested urban use case is much more challenging to get right, and much more likely to rely on an dynamic ETA estimate. If you're on a multi-hour trip, you're more likely to have scoped out your travel time before you leave and planned accordingly, and if that estimate is off by perhaps 30 minutes, that's usually not the end of the world. For many phone navigation apps, the commuting use case is front and center, because the route people take to and from work will depend a lot on live traffic conditions. (Remember Waze's slogan - outsmarting traffic together, or something). So it's really navigation and ETA going hand in hand to deliver the user the optimal way to work or home. On Tue, Sep 9, 2014 at 3:00 PM, Tod Fitch t...@fitchdesign.com wrote: Yes, a pretty small use case at somewhere around 10,000,000 trips per year on I-5 through the central valley of California. Or 9,000,000 trips per year each way on I-8 across the desert to the Arizona border. On your daily commute, you may not need help navigating so much as you want accurate real time information about which routes are moving well compared to others. For me, trip planning and using a navigation device is not for local driving (I mostly use OsmAnd for local driving to help me find errors in OSM data) as much as for getting me to places I don't go on a daily basis. You could say it is a pretty small use case as most people don't drive to or through unfamiliar places everyday, but it is probably the biggest use case for a nav system there is. Cheers, Tod On Sep 9, 2014, at 1:17 PM, Martijn van Exel wrote: Agreed - that's a pretty small use case, relatively, though. On Tue, Sep 9, 2014 at 1:38 PM, Tod Fitch t...@fitchdesign.com wrote: Historical and live speed profiles are pretty much required for trip planning in congested urban areas, but for those of us who drive close to the speed limit and make long trips on relatively uncrowded rural freeways, travel time estimates based on posted (or prima facie) speeds are a good approximation to reality. I travel between northern California and southern Arizona a lot. The distance is about 1,300 kilometers and only a small fraction of that is congested urban freeways (especially if I decide, as I usually do, to avoid Los Angeles). OsmAnd with its knowledge of actual posted speed limits (many entered by me) does a very good job at predicting my arrival time. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-cl] Promover el uso de la bicicleta como medio de transporte
Hola, Normalmente me muevo en bicicleta, y hasta el momento no he encontrado una app que recomiende rutas tomando en cuenta el medio de transporte que uso, es por ello que estoy actualizando el sitio de OpenStreetMap Chile(para poder usar este desde un smartphone) Me interesa fomentar el uso de la bicicleta implementando nuevas funcionalidades al sitio de la comunidad, y mejorar los datos de OSM que se usan para recomendar rutas, quizás usar datos de trafico para mejorar la recomendación. Es por lo anterior que me interesa saber si es posible participar en http://hack4goodsantiago.github.io/ presentando el proyecto de hacer mejoras al sitio de la comunidad orientadas a la bicicleta como medio de transporte. Si hay gente interesada podemos conversar por la lista y/o nos vemos en hack4goodsantiago. Saludos -- *Juan Pizarro* *Mob:* *E-Mail:* +56 9 75891972 jpizar...@gmail.com jpiza...@doingit.cl - OpenStreetMap.cl: El Mapa Libre del Mundo ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
