Re: [OSM-talk] Best base to build on ...
On 15/08/15 20:57, Paul Norman wrote: The obvious question is that given tilemill is not longer being maintained, what are the preferred alternatives? Kosmtik is the preferred alternative to Tilemill, but both of these are style design programs, not programs for serving tiles to others. I have no doubt that you could proxy them via a caching proxy, but this is a horrible idea. I have something building tiles how *I* want them to look via tilemill but having spent a couple of hours on kosmtik I can't even get it to install. Use any one of the standard tile rendering servers like renderd+mod_tile or tirex+mod_tile. If you don't need update support (which you don't if you were considering Tilemill) then mapproxy, tilestash, tilecache, and non-OSM specific options are available. Getting something actually working with my working tilemill style is something else I've been wasting time on :( The simple answer seems to be that there is no standard when it comes to mapping applications and everybody creates their own personal special such as kosmtik rather than working with established standards :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Best base to build on ...
On 8/15/2015 2:09 PM, Lester Caine wrote: The simple answer seems to be that there is no standard when it comes to mapping applications and everybody creates their own personal special such as kosmtik rather than working with established standards:( Kosmtik is a standard. But it's a development tool for stylesheet design. The other options are Mapbox Studio and Tilemil. All three are essentially desktop applications, although the developer using them might interact with them via a browser. The former doesn't support a raster tile style, has tie-ins with Mapbox that make it difficult to use independently, and does not work reasonably with styles in version control. The problem with Tilemill is that is is abandoned, and includes in-program text editing, which adds significant complexity to the codebase, and this text editing does not function with large complex styles. It's also not a question of duplication, as all of these options are written in nodejs and the map rendering parts share common modules. renderd, and all similar software, serves a completely different purpose, and are not good options for applications where Kosmtik, Tilemill, and Mapbox Studio make sense. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] bâtiment fractionné
Bonjour, Le 15/08/2015 23:25, osm.sanspourr...@spamgourmet.com a écrit : Osmose tique assez logiquement sur des bâtiments fractionnés. Quand un même bâtiment se trouve sur deux parcelles cadastrales, doit-on le fusionner ou indiquer faux positif ? http://wiki.openstreetmap.org/wiki/FR:Osmose/issues#1 est peu bavard sur le sujet ! Il y a un osmecum sur le bâti : http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum#Int.C3.A9grer_le_b.C3.A2ti -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Taginfo updates
El 15/08/2015 10:26 am, Jochen Topf escribió: Hi! Taginfo got an update this week. Together with Cristopher Baines I worked on making it a bit more mobile friendly. Some bugs were fixed and some parts that were rather slow are much faster now. But the biggest news is the new taglist feature: Taginfo can now automatically generate the tags tables you see all over the OSM wiki. See http://wiki.openstreetmap.org/wiki/Taginfo/Taglists for how this works. This should be very useful to reduce the manual work needed for updating the wiki. Try it out at: https://taginfo.openstreetmap.org/ Details about all of this at: http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Thank you! Eduardo ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 15/08/2015 10:08 PM, Lester Caine wrote: On 15/08/15 12:55, Colin Smale wrote: Good question. We assume they were not entered from sources without a suitable licence. Should we delete them? I certainly don't need to know where the gas pipelines are. But someone buying a house close by may be interested? A number of pipelines have been laid around here and we could have plotted their routes as the various roads were dug up and trenches cut ... Someone digging a hole (for a planting tree as an example) may be very interested in where things are underground. There are also roads and train lines that are underground. Those are mapped in OSM .. and they are not 'on the ground' nor could I verify them - the GPS stops working inside the tunnels. Yet I would not suggest they be removed! I know they are there .. and the position is approximately correct as far as I can determine (entry points are good, direction of travel is good and the shape complies with my impression of it). So .. Deletion .. for me ... only where the feature is entirely removed and replaced with another feature. If a feature is abandoned, raised etc, leave the nodes/way there and change the tag... add the prefix demolished: Where there is doubt, do nothing! Doubt should be removed before acting, asking the originator may remove doubt. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] bâtiment fractionné
Bonjour Osmose tique assez logiquement sur des bâtiments fractionnés. Quand un même bâtiment se trouve sur deux parcelles cadastrales, doit-on le fusionner ou indiquer faux positif ? http://wiki.openstreetmap.org/wiki/FR:Osmose/issues#1 est peu bavard sur le sujet ! Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On 15/08/15 23:04, Paul Norman wrote: 17 117 occurences is not 'not in the database'. No, a key not in https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style is not in the database. landcover is not in that list, so is not in the database. The data is in the database ... The difference is that the view of that data extracted currently by openstreetmap-carto.style simple excludes them. This is the same mechanism by which a view of the data can also be filtered to omit or include data for a particular time frame, or which has been expired via a stop_date ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On 8/15/2015 1:15 PM, Ruben Maes wrote: 17 117 occurences is not 'not in the database'. No, a key not in https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style is not in the database. landcover is not in that list, so is not in the database. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 15 August 2015 16:29:56 GMT+01:00, Russ Nelson nel...@crynwr.com wrote: Are we even talking about the same thing? Let's assume that you made a s mple t po. Don't those last two words look a little weird with missing bits? Shouldn't those letters be there? Shouldn't the dismantled bits of a railroad be in OSM as dismantled bits? That metaphor is a bit of a strech. Let's bring it closer to reality with http://osm.org/go/esT4qhWnF these WWII signs which are technically just stones in a field. What if some real-life vandal removed the stones of one letter and nobody repaired the damage long enough that all signs of the former letter are gone ? You're arguing for some kind of *=razed tag, while I (and probably most other osm contributors, who arent wwii-stone-markings enthusiasts experts in deducing a former sign from peripheral hints) would argue for deleting the non-existing letter from osm. even if it's only because you can look left and see evidence of the railroad, and you can look right and see evidence of the railroad. Should they NOT be mapped through the farmer's field where they have been plowed into dismantlement? It's a circular argument at this stage, but yes if the ground there has been flattened and ploughed, osm should IMHO not map anything else than the field. I'd support deletion of that railway section in such a case, but of course it should be discussed with the other contributors. As a last resort, the DWG can arbitrate between two parties. Now, I'm sure somebody will, at some point say, Russell, just go off to OpenHistoricalMap and put your data there. That's fine, except for those pesky implementation details where THEY ARE IN TWO DISPARATE DATABASES, UNCONNECTED. How, exactly, do you make a relation that shows the entire route of a railroad when half of it is off in a different corner? That's clearly a big pain point of ohm. But it isn't an insurmountable one, hopefully ohm will eventually manage a continous merge of osm data as a 'present day layer'. I don't understand why we're having this argument. We map tons of things that you can't see. Why not map as dismantled railroads that have been dismantled? Why not make an exception to the Delete it if you don't see it guideline? The existence of ohm is a strong aknowlegement that osm is only for the present. Russ, you're an expert in old railroads, but think of all the other old things you could be an expert of. If all the niche experts got their exception, the osm tools, cpnsumers, and contributors would suffer heavily from all the historical data. In its curent state, osm isn't fit for historical data (end_date and other lifecycle tags are only good enough for some narrow cases of objects that still exist in some deteriorated form and haven't been recycled yet). Hopefully someday the ohm framework will be mature enough to be adopted by osm, so that we can map in time as well as in space (better tools to map in the 3rd dimention would be great too). In the meantime, please only map the present in osm. -- Vincent Dp ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 16/08/2015 1:29 AM, Russ Nelson wrote: Warin writes: On 15/08/2015 3:46 PM, Russ Nelson wrote: Railway=dismantled. Doesn't get rendered except where it should be, do you still want railway=disused to remain? Are we even talking about the same thing? Let's assume that you made a s mple t po. No .. just two things at once. Sorry .. should have been Where the railway has completely gone, do you still want Railway=dismantled to be used. And your answer is yes (I think). Lookit, I'm also a fan of unfinished railroads. http://russnelson.com/unfinished-railroads.html You don't see me insisting that the unbuilt sections of these railroads get mapped, do you? No, because they never existed, and you can't see any evidence that they did. W There is also proposed, planned... and under construction. Proposed and planned I cannot verify .. many things get 'proposed' or 'planned' by politicians .. and there is no sight of them for many decades if at all. Under construction I should be able to verify. Now, I'm sure somebody will, at some point say, Russell, just go off to OpenHistoricalMap and put your data there. That's fine, except for those pesky implementation details where THEY ARE IN TWO DISPARATE DATABASES, UNCONNECTED. How, exactly, do you make a relation that shows the entire route of a railroad when half of it is off in a different corner? Good question. Pose it on OpenHistoricalMap ? Maybe they have a solution. I don't understand why we're having this argument. Discussion. Well as far as I'm concerned. I WILL BE HAPPY AND GO AWAY WITH AN EXCEPTION. Don't you want me to be happy? Don't you want me to go away? No I, for one, don't want you to go away. Quite the contrary! I do take your point... You want old things that may no longer be present in any shape or form to be represented ? within OSM? I sympathise. But is OSM the place for these? (I'd call them 'ghosts', visions of things past.) However ... Why stop with railways? Roads and buildings have history too. Some OSM people mantra on about verification. How are these things to be verified? Umm the old 'Tank Stream' in Sydney ... that was a fresh water source for the establishment of Sydney. Most, if not all, of it is underground. Should that be mapped as demolished:waterway=stream and then other tags to reflect what it is now .. ? Probably. But I would have problems with verifying its' location. Humm.. So I'd not let 'us' (as in OSM) off with some exception just for railways, other things should have the same consideration. You have raised a good issue. An it is a policy issue .. and OSM is not good with policy. Hence this lengthy thread heading off in may directions. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] bâtiment fractionné
Si physiquement ce n'est qu'un bâtiment, le découper en parcelles n'a pas de sens, il faut donc fusionner. Parfois cela correspond à des bâtiments séparés et cela a du sens de les laisser tels quels. L'exemple le plus évident est celui des immeubles en ville. La majorité du temps, il faut fusionner. C'est ce qu'on demande quand les gens intègrent le cadastre, mais si déjà le positionnement et les erreurs sont corrigées, c'est déjà un bon import. Le 15 août 2015 23:26, osm.sanspourr...@spamgourmet.com a écrit : Bonjour Osmose tique assez logiquement sur des bâtiments fractionnés. Quand un même bâtiment se trouve sur deux parcelles cadastrales, doit-on le fusionner ou indiquer faux positif ? http://wiki.openstreetmap.org/wiki/FR:Osmose/issues#1 est peu bavard sur le sujet ! Jean-Yvon ___ 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] stop deleting abandoned railroads
On 16/08/2015 1:35 AM, Russ Nelson wrote: Serge Wroclawski writes: Our project's policy thusfar has been in contrast to other projects in that each and every one of us is empowered to make changes to anything we see. You're starting to understand! You should make changes to things you see. Things you don't see require a higher standard of knowledge. This leaves our project with a problem of lots of data and no one feeling empowered to remove it. Seriously? THIS is your line of reasoning? There's a simple way to empower them: If it's got TIGER tags and you don't see it, delete it. TIGER tags? Don't they only occur in one area of the world? Rather a small view of the world then. Done. Next problem. Not done. For example I have deleted roads in the middle of houses, a clear error, possibly mine, and yes I did go and look on foot. I don't think there are any TIGER tags at all within 8,000miles. And I have no problem with that deletion. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Intégration des numéros de porte
Bonjour à tous, J'ai remarqué que dans les grandes villes, les numéros des bâtis étaient indiqués partout partout partout et ça c'est super. En revanche dans des villes moyennes comme Dieppe, ils ne sont pas renseignés. Pourquoi ? - Est-ce parce qu'elles ne sont pas disponibles dans la BANO ? - Est-ce que parce que ça demande du temps à les intégrer et personne ne s'en est encore occupé dans ces territoires là ? (il y a des outils pour faciliter leur intégration ou faut-il le faire à la main ?) - Est-ce par un soucis de fiabilité et mieux vaut ne pas les intégrer qu'intégrer des données non fiables ? S'il n'y a pas de raison bloquante, alors j'y prendrai un malin plaisir à les renseigner :) Mais dans ce cas pourriez-vous me guider afin de ne pas faire d'erreur ? Merci pour vos réponses. A bientôt ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] stop deleting abandoned railroads
On 15/08/2015 7:19 PM, Volker Schmidt wrote: I would like to argue for a general do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy for these and similar cases. I have myself mapped a couple of abandoned railways where the remains were often no longer recognizable individually as traces of a former railway, but as a whole, in particular in satellite photos it is clearly visible. This includes roads, paths, and vegetation strips that mark the former track, and former railway buildings. In my case the specific interest is to keep the memory of these former railway routes alive with the scope to have documentation ready to argue for the (partial) re-utilization as bicycle routes. Two other types of routes, not railway-related, also spring to mind: Historic Route 66 (which is actually being recreated as an official USBRS route for cycle tourists, trying to follow as much as possible the original roads). Unfortunately there are many people interested in old Route 66 ... Tours from Australia have been done .. and I think that is now a yearly event where a group of Australian tourist go over, hire a car (each or in pairs) and travel as much of Route 66 as possible .. with a guide or two. Another example where historic roads have traditional appeared on maps are the Roman Roads on UK Ordnance Survey maps. There are remnants of old Highway 1 in Australia ... not much interest in them. Some bits are handy for camping on. I wonder if the old Ghan Railway line is tagged in OSM? It is a tourist attraction. ,,, checking... Yes it is there, and can be seen on the bing sat photos. Tagged as 'disused' rather than abandoned. It is both! But at least some it it remains - bridges over rivers (when they run), some stations with water tanks for the steam locomotives. One of the bridges I'm looking at .. does not have the river tagged! Shows how often it runs, and the importance of the old railway line. I'll just go and tag that bit of the river now. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
So who decides what is good data and what is bad data? And visibility on the ground needs nuancing. Are we to remove underground pipelines/power lines? Or boundaries? Visible and/or verifiable might be better. A rule that needs loads of exceptions, is not a well formed rule. An abandoned railway route IS an abandoned railway route, even today (i.e. that is current data). It WAS a working railway line. That is all verifiable. On 2015-08-15 12:31, Serge Wroclawski wrote: On Sat, Aug 15, 2015 at 5:19 AM, Volker Schmidt vosc...@gmail.com wrote: I would like to argue for a general do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy for these and similar cases. Then you are (whether or not you intend it) arguing in favor of dis-empowering users. Our project's policy thusfar has been in contrast to other projects in that each and every one of us is empowered to make changes to anything we see. We certainly have policies in regards to quality control- if someone makes a bad edit, we revert it, but we are always in favor of the empowerment of our users to fix problems, rather than saying that they can't, or need to ask permission beforehand. Let's be very clear on the issue in this case- it's regarding a very subtle line of objects which are in one of two states: 1. Visible on the ground but difficult to detect (ie require specialized knowledge) or 2. No longer visible at all. The problem that we have in some parts of the world is a lack of data, but in other parts, we have an abundance of bad imports, and a general timidness around the removal of data that we can't find the owner of, which leaves us with data that *we know is bad*, but where the individual mappers do not feel empowered to act on because of this exact attitude of needing to contact and work with the importer. This leaves our project with a problem of lots of data and no one feeling empowered to remove it. If we continue to go down that road, we will be left in an untenable situation of living in the data equivalent of a hoarder's house. I'm very much in favor of mapper to mapper collaboration. In fact I am the person who mentored the GSoC project to add changeset discussions, but I do not believe we want to change the project's culture into one where no one feels empowered to edit the map without first asking permission. - Serge ___ 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] stop deleting abandoned railroads
On Sat, Aug 15, 2015 at 6:43 AM, Colin Smale colin.sm...@xs4all.nl wrote: So who decides what is good data and what is bad data? The community as a whole decides what is good and bad data. That starts with the local community and moves up to the OSM community as a whole in terms of whether or not data belongs in OSM or not. And visibility on the ground needs nuancing. Are we to remove underground pipelines/power lines? If you were able to go underground, then you'd find such data. But if you can't- how do you know these lines exist? You probably are using a feature that you *can* see without being underground. Or boundaries? I specifically addressed political boundaries in my previous mail. Visible and/or verifiable might be better. A rule that needs loads of exceptions, is not a well formed rule. Verifiable and visible are essentially synonymous in this discussion. An abandoned railway route IS an abandoned railway route, even today (i.e. that is current data). It WAS a working railway line. That is all verifiable. Yes, but we don't map things that used to be present but are no longer present. A road used to be here but is now a building. We don't map the old road, only what's present now. - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
I would like to argue for a general do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy for these and similar cases. I have myself mapped a couple of abandoned railways where the remains were often no longer recognizable individually as traces of a former railway, but as a whole, in particular in satellite photos it is clearly visible. This includes roads, paths, and vegetation strips that mark the former track, and former railway buildings. In my case the specific interest is to keep the memory of these former railway routes alive with the scope to have documentation ready to argue for the (partial) re-utilization as bicycle routes. Two other types of routes, not railway-related, also spring to mind: Historic Route 66 (which is actually being recreated as an official USBRS route for cycle tourists, trying to follow as much as possible the original roads). Another example where historic roads have traditional appeared on maps are the Roman Roads on UK Ordnance Survey maps. Best regards from Italy Volker ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On Sat, Aug 15, 2015 at 5:19 AM, Volker Schmidt vosc...@gmail.com wrote: I would like to argue for a general do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy for these and similar cases. Then you are (whether or not you intend it) arguing in favor of dis-empowering users. Our project's policy thusfar has been in contrast to other projects in that each and every one of us is empowered to make changes to anything we see. We certainly have policies in regards to quality control- if someone makes a bad edit, we revert it, but we are always in favor of the empowerment of our users to fix problems, rather than saying that they can't, or need to ask permission beforehand. Let's be very clear on the issue in this case- it's regarding a very subtle line of objects which are in one of two states: 1. Visible on the ground but difficult to detect (ie require specialized knowledge) or 2. No longer visible at all. The problem that we have in some parts of the world is a lack of data, but in other parts, we have an abundance of bad imports, and a general timidness around the removal of data that we can't find the owner of, which leaves us with data that *we know is bad*, but where the individual mappers do not feel empowered to act on because of this exact attitude of needing to contact and work with the importer. This leaves our project with a problem of lots of data and no one feeling empowered to remove it. If we continue to go down that road, we will be left in an untenable situation of living in the data equivalent of a hoarder's house. I'm very much in favor of mapper to mapper collaboration. In fact I am the person who mentored the GSoC project to add changeset discussions, but I do not believe we want to change the project's culture into one where no one feels empowered to edit the map without first asking permission. - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Intégration des numéros de porte
C'est en général un défaut, de temps, même avec une armée de volontaire, on ne peut pas tout faire. Le site cadastre.openstreetmap.fr permet de faciliter le positionnement. Cependant dans certains cas les numéros de rues ne sont pas présents sur le cadastre (Laroquebrou par exemple). Il faut vérifier avec le cadastre. Bon courage pour remplir ta ville :) Le Samedi 15 août 2015 11h26, Aurélien kinj...@gmail.com a écrit : Bonjour à tous, J'ai remarqué que dans les grandes villes, les numéros des bâtis étaient indiqués partout partout partout et ça c'est super. En revanche dans des villes moyennes comme Dieppe, ils ne sont pas renseignés. Pourquoi ? - Est-ce parce qu'elles ne sont pas disponibles dans la BANO ? - Est-ce que parce que ça demande du temps à les intégrer et personne ne s'en est encore occupé dans ces territoires là ? (il y a des outils pour faciliter leur intégration ou faut-il le faire à la main ?) - Est-ce par un soucis de fiabilité et mieux vaut ne pas les intégrer qu'intégrer des données non fiables ? S'il n'y a pas de raison bloquante, alors j'y prendrai un malin plaisir à les renseigner :) Mais dans ce cas pourriez-vous me guider afin de ne pas faire d'erreur ? Merci pour vos réponses. A bientôt ___ 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] osmose: analyse croisement BANO/OSM à tester...
Effectivement, le '.' n'était pas bien pris en compte dans la comparaison OSM/Route500. C'est corrigé. Le 14 août 2015 07:11, didier2020 didier2...@free.fr a écrit : slt, je pense qu'il y a une amélioration a faire sur les route avec indice comme ici : http://osmose.openstreetmap.fr/fr/map/#zoom=16lat=48.35267lon=1.30634item=7170 osm vs route500 D 129.3 vs D129.3 Le mercredi 05 août 2015 à 14:16 +0200, Christian Quest a écrit : Le 05/08/2015 11:33, Yves Pratter a écrit : Pour l'instant c'est en test uniquement sur le serveur dev d'osmose, il est préférable d'avoir vos retours avant de mettre ça sur l'instance de prod, donc c'est ici: http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=33 (voies à tracer) Nickel pour les quelques cas que j’ai regardé : lotissement en construction ou rues bien visibles sur Bing :) http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32 (name à ajouter) Correct. La puce n’est pas exactement sur le tracé de la route… et surtout il y a des rues aux alentours sans noms et sans retour de la part d’Osmose : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32zoom=17lat=46.940308lon=6.03245layer=Mapnik-osmfroverlays=FFFT Oui, l'analyse pêche par excès de prudence ;) Souvent quand un manque est signalé il y a du grain à moudre sur la zone... http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=31 (name à modifier) Semble correct. Idem pour la puce http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30 (cas ambigus) Là c’est plus problématique. Il en sort pleins (peut-être celles qui manques pour « name à ajouter » ?) Beaucoup ? de faux positifs : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=17lat=46.914597lon=6.30978layer=Mapnikoverlays=FFFT Ici une rue est correctement nommée, l’autre est à corriger (Rue du Tilleul à la place de Rue des Tilleuls ») Bien sûr la limite ce sont les noms récupérées par les scripts BANO sur le cadastre... si ils sont incorrects, osmose va proposer une correction qui n'a pas lieu d'être. L'analyse tient compte des signalements faits sur http://cadastre.openstreetmap.fr/fantoir/ Les voies où l'on a indiqué un problème sont éliminées de l'analyse. http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=16lat=46.9126lon=6.3407layer=Mapnikoverlays=FFFT Rue Branly proposé à la place de Rue Édouard Branly, idem pour Eiffel, Mermoz… Propose « Rue Edgard Fauré » avé l’assent ;-) … Pareil... à signaler sur http://cadastre.openstreetmap.fr/fantoir/ L'analyse pourrait aussi proposer l'ajout du ref:FR:FANTOIR plutôt que de juste proposer de changer le name=*. C'est un moyen d'indiquer que c'est la bonne voie (BANO pourra faire son rapprochement) même si le libellé ne correspond pas (et donc que c'est une erreur dans FANTOIR). Je vais voir pour ajouter ça dans les cas de noms divergents. -- 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] stop deleting abandoned railroads
On 15/08/2015 3:46 PM, Russ Nelson wrote: Mateusz Konieczny writes: In another case where railway tracks that were removed, embankment demolished and somebody build there houses. In that case railway track should not be mapped in OSM because this feature is gone. Railway=dismantled. Doesn't get rendered except where it should be, on openrailwaymap.org. Why is this so hard? I'm not asking you to do it. I'm asking you to stop preventing me from doing it. I'm not trying to make extra work for anybody. I'm asking you to find a different way to make the map better than by deleting things, valid things, real things, that other people entered. Russ ... if the railway has been removed ... and another use has taken over totally and nothing remains (so no real things remain)... do you still want railway=disused to remain? Personally when some feature has been replaced with another feature... such that nothing remains of the original .. I'd be inclined to delete. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...
cool ! j'en profite pour te remercier de ces dernieres idees qui sont une aide précieuse pour les ajouts/corrections Le samedi 15 août 2015 à 13:23 +0200, Christian Quest a écrit : Effectivement, le '.' n'était pas bien pris en compte dans la comparaison OSM/Route500. C'est corrigé. Le 14 août 2015 07:11, didier2020 didier2...@free.fr a écrit : slt, je pense qu'il y a une amélioration a faire sur les route avec indice comme ici : http://osmose.openstreetmap.fr/fr/map/#zoom=16lat=48.35267lon=1.30634item=7170 osm vs route500 D 129.3 vs D129.3 Le mercredi 05 août 2015 à 14:16 +0200, Christian Quest a écrit : Le 05/08/2015 11:33, Yves Pratter a écrit : Pour l'instant c'est en test uniquement sur le serveur dev d'osmose, il est préférable d'avoir vos retours avant de mettre ça sur l'instance de prod, donc c'est ici: http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=33 (voies à tracer) Nickel pour les quelques cas que j’ai regardé : lotissement en construction ou rues bien visibles sur Bing :) http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32 (name à ajouter) Correct. La puce n’est pas exactement sur le tracé de la route… et surtout il y a des rues aux alentours sans noms et sans retour de la part d’Osmose : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32zoom=17lat=46.940308lon=6.03245layer=Mapnik-osmfroverlays=FFFT Oui, l'analyse pêche par excès de prudence ;) Souvent quand un manque est signalé il y a du grain à moudre sur la zone... http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=31 (name à modifier) Semble correct. Idem pour la puce http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30 (cas ambigus) Là c’est plus problématique. Il en sort pleins (peut-être celles qui manques pour « name à ajouter » ?) Beaucoup ? de faux positifs : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=17lat=46.914597lon=6.30978layer=Mapnikoverlays=FFFT Ici une rue est correctement nommée, l’autre est à corriger (Rue du Tilleul à la place de Rue des Tilleuls ») Bien sûr la limite ce sont les noms récupérées par les scripts BANO sur le cadastre... si ils sont incorrects, osmose va proposer une correction qui n'a pas lieu d'être. L'analyse tient compte des signalements faits sur http://cadastre.openstreetmap.fr/fantoir/ Les voies où l'on a indiqué un problème sont éliminées de l'analyse. http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=16lat=46.9126lon=6.3407layer=Mapnikoverlays=FFFT Rue Branly proposé à la place de Rue Édouard Branly, idem pour Eiffel, Mermoz… Propose « Rue Edgard Fauré » avé l’assent ;-) … Pareil... à signaler sur http://cadastre.openstreetmap.fr/fantoir/ L'analyse pourrait aussi proposer l'ajout du ref:FR:FANTOIR plutôt que de juste proposer de changer le name=*. C'est un moyen d'indiquer que c'est la bonne voie (BANO pourra faire son rapprochement) même si le libellé ne correspond pas (et donc que c'est une erreur dans FANTOIR). Je vais voir pour ajouter ça dans les cas de noms divergents. -- 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 ___ Talk-fr mailing list
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On 15 August 2015 14:16:06 GMT+01:00, Martin Koppenhoefer dieterdre...@gmail.com wrote: IMHO it would rather encourage mappers to make more sense out of these than it is now. I'm myself adding a pointless landuse=forest for every landcover=trees now (for the renderer), and I guess most other mappers do the same. I will remove them from non-forests as soon as the landcover tag becomes visible Yes, landcover=trees has the notable advantage of being unambiguous, because it only conveys one concept. The other concepts confusedly conveyed by landuse=forest and natural=wood can/should be handled by other tags (landuse=forestry anyone ? :) ). It'll take years if it happens at all, but getting early support from osmcarto will speed things up. -- Vincent Dp ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-co] Día Mundial Humanitario - Agenda
El 19 de agosto es miercoles, intentare asistir. El día 15 de agosto de 2015, 12:05, hyan...@gmail.com hyan...@gmail.com escribió: Estimados maperos: Buenos días. Me place informarles que el próximo jueves 19 de agosto se estará llevando a acabo el evento Día Mundial Humanitario en la ciudad de Bogotá. En el cual se estará presentando el proyecto de mapeo en Salgar, Antioquia. Sería de mucho agrado que la comunidad estuviera presente, conocernos y estrechar lazos! Saludos, Humberto Yances Día Mundial Humanitario 2015 VII Encuentro de actores sociales en temas humanitarios Martes 28 de julio de 2015, por Isabel Suarez El Día Mundial Humanitario (DMH) es el día en el cual le rendimos un homenaje a los trabajadores humanitarios que han perdido sus vidas y a aquellos que continúan arriesgándola todos los días con el fin de proporcionar ayuda a los necesitados. Este día actualmente es establecido como una celebración global de espíritu humanitario. El 19 de agosto de 2015, se llevará a cabo el VII Encuentro de actores sociales en temas humanitarios, en el marco del Día Mundial Humanitario, en donde se mostraran los avances en investigación y experiencias en el trabajo humanitario, para una comprensión pública mundial, elogiando las acciones ejercidas por aquellos que dedican su vida a la acción humanitaria. Hora: 8:30 am Lugar: Universidad Santo Tomás (Edificio Dr. Angélico, Carrera 9 No. 72 - 90. Aula Magistral 401) ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co -- Juan Carlos Pachón Twitter @Arttesano http://arttesano.com 57-1-3102694942 Skype : arttesano ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]
On 15 August 2015 14:23:09 GMT+01:00, Martin Koppenhoefer dieterdre...@gmail.com wrote: you are mistaken, the motivation for landcover was not connected to the natural (as in nature) and managed idea. Usually the distinction between wood and forest is size and density, the distinction between natural and landuse is about named entities vs. the usage by man attribute. A group of trees in the park is sometimes a wood but never a forest. Landcover has a point besides trees (think grass for instance) This is a perfect example of the confusion around landuse=forest vs natural=wood. Size and density ? Managed ? Named ? Usage type ? The curent osm data is a mix of all these criterias an more; at this stage it is hopeless for the consumer to extract more meaning than 'here be trees'. Landcover=trees is rightly calling these nuances a loss and trying a fresh clean approach. -- Vincent Dp ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Best base to build on ...
I'm not sure how TileMill fits within your rendering stack here. Do you mean Mapnik? If you talk about carto-based style development the best alternative for TileMill right now is Kosmtik (https://github.com/kosmtik/kosmtik), which is developed and maintained by Yohan Boniface. Some if not all of the maintainers of osm-carto use it. I have also switched from TileMill to Kosmtik for my work on osm-carto a few months ago. It is addressing the more tech-savvy kind of style developers (more command-line stuff), but the switch has also optimized my workflow. Best, nebulon42 Am 2015-08-15 um 17:14 schrieb Lester Caine: Not getting much help on the GB list so I thought I'd widen the question. A couple of years back I had my own server setup working with a base of OSRM and routing covering the UK. While the map server is still working, routing has packed up and some of the alternate base maps are no longer accessible. Given that the OSM styling is going to switch to something which in my book is unacceptable I needed to sort my own rendering as a base for UK usages. I've got tilemill running finally with a few niggles, but I've actually managed to switch some style elements to be more UK frindly using darker road colours. But as yet I've not got the routing side working again. The obvious question is that given tilemill is not longer being maintained, what are the preferred alternatives? I'm actually not happy with the way OSRM has moved and there does not seem to be a 'standard' for the support structure? Each section seems to need a different set of tool versions. I'm happy to have to use postgresql despite having had two corruptions already, but mysql has no place here. My main stack is Nginx, PHP and Firebird and I have tilemill running on top of that, and the planet file is being replicated nicely. So do I spend a lot more time on tilemill, or am I better switching before spending too much more time on that, and what other options are available to replace OSRM. OSMAND is working well for me in the car so is that perhaps a better use of time given that I still have a time hungry support service to provide ... and I still need OHM as an option ... I need to get this machine configured before shipping over to the data centre where it will sit on a high speed pipe so I need to get it right. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] osmose: analyse croisement BANO/OSM à tester...
À noter que les indices (plus souvent affichés d'ailleurs en exposants sur les panneaux...) sont aussi des lettres comme D 142.B, parfois de chiffres pour différencier par exemple des bretelles d'accès à sens unique par exemple D 142.B2. Normalement dans osm il n'y a pas de point séparateur mais j'ai parfois vu des tirets comme D142-B2 ou D 142-2. La doc du wiki précise bien qu'on met une espace en France entre le type de route et son numéro, mais il ne semble pas y avoir de convention pour les indices exposant, et le plus souvent si l'indicekexposant commence par une lettre, il n'y a aucun séparateur du tout le séparant du numéro principal et on obtient D 142B. l'autre problème est pour les indices d'ordre latins bis, ter, etc. qui sont parfois abrégés B, T, etc. on a la même ambiguïté aussi pour les numéros de maisons d'une rue d'ailleurs et le wiki ne précise pas bien la convention d'autant plus que le cadastre emploie ces abréviations et on doit deviner le sens de la lettre par la présence ou l'absence d'une lettre A qui devrait être présent sur un nœud voisins, ce qui n'est pas toujours le cas... on devrait mettre les indices d'ordre latins en minuscules et sans les abréger, donc 142bis et non 142B bien que cela semble équivalent pour indiquer le second rang, mais avec l'ambiguïté sur le numero precedent ou suivant... pourtant certains d'ici utilisent les abreviations de bis/ter... en B/T... Le 15 août 2015 13:25, Christian Quest cqu...@openstreetmap.fr a écrit : Effectivement, le '.' n'était pas bien pris en compte dans la comparaison OSM/Route500. C'est corrigé. Le 14 août 2015 07:11, didier2020 didier2...@free.fr a écrit : slt, je pense qu'il y a une amélioration a faire sur les route avec indice comme ici : http://osmose.openstreetmap.fr/fr/map/#zoom=16lat=48.35267lon=1.30634item=7170 osm vs route500 D 129.3 vs D129.3 Le mercredi 05 août 2015 à 14:16 +0200, Christian Quest a écrit : Le 05/08/2015 11:33, Yves Pratter a écrit : Pour l'instant c'est en test uniquement sur le serveur dev d'osmose, il est préférable d'avoir vos retours avant de mettre ça sur l'instance de prod, donc c'est ici: http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=33 (voies à tracer) Nickel pour les quelques cas que j’ai regardé : lotissement en construction ou rues bien visibles sur Bing :) http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32 (name à ajouter) Correct. La puce n’est pas exactement sur le tracé de la route… et surtout il y a des rues aux alentours sans noms et sans retour de la part d’Osmose : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=32zoom=17lat=46.940308lon=6.03245layer=Mapnik-osmfroverlays=FFFT Oui, l'analyse pêche par excès de prudence ;) Souvent quand un manque est signalé il y a du grain à moudre sur la zone... http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=31 (name à modifier) Semble correct. Idem pour la puce http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30 (cas ambigus) Là c’est plus problématique. Il en sort pleins (peut-être celles qui manques pour « name à ajouter » ?) Beaucoup ? de faux positifs : http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=17lat=46.914597lon=6.30978layer=Mapnikoverlays=FFFT Ici une rue est correctement nommée, l’autre est à corriger (Rue du Tilleul à la place de Rue des Tilleuls ») Bien sûr la limite ce sont les noms récupérées par les scripts BANO sur le cadastre... si ils sont incorrects, osmose va proposer une correction qui n'a pas lieu d'être. L'analyse tient compte des signalements faits sur http://cadastre.openstreetmap.fr/fantoir/ Les voies où l'on a indiqué un problème sont éliminées de l'analyse. http://dev.osmose.openstreetmap.fr/fr/map/#item=7170class=30zoom=16lat=46.9126lon=6.3407layer=Mapnikoverlays=FFFT Rue Branly proposé à la place de Rue Édouard Branly, idem pour Eiffel, Mermoz… Propose « Rue Edgard Fauré » avé l’assent ;-) … Pareil... à signaler sur http://cadastre.openstreetmap.fr/fantoir/ L'analyse pourrait aussi proposer l'ajout du ref:FR:FANTOIR plutôt que de juste proposer de changer le name=*. C'est un moyen d'indiquer que c'est la bonne voie (BANO pourra faire son rapprochement) même si le libellé ne correspond pas (et donc que c'est une erreur dans FANTOIR). Je vais voir pour ajouter ça dans les cas de noms divergents. -- 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 -
Re: [Talk-co] Día Mundial Humanitario - Agenda
Va a ser genial que esa experiencia se comparta ! Porfa si graban o tienen documentos de la presentación se los agradezco! Un abrazo desde Sierra Leona Luis Sent from Samsung Mobile Original message From: Artesano arttes...@gmail.com Date:2015/08/15 17:49 (GMT+00:00) To: OpenStreetMap Colombia talk-co@openstreetmap.org Cc: Subject: Re: [Talk-co] Día Mundial Humanitario - Agenda El 19 de agosto es miercoles, intentare asistir. El día 15 de agosto de 2015, 12:05, hyan...@gmail.com hyan...@gmail.com escribió: Estimados maperos: Buenos días. Me place informarles que el próximo jueves 19 de agosto se estará llevando a acabo el evento Día Mundial Humanitario en la ciudad de Bogotá. En el cual se estará presentando el proyecto de mapeo en Salgar, Antioquia. Sería de mucho agrado que la comunidad estuviera presente, conocernos y estrechar lazos! Saludos, Humberto Yances Día Mundial Humanitario 2015 VII Encuentro de actores sociales en temas humanitarios Martes 28 de julio de 2015, por Isabel Suarez El Día Mundial Humanitario (DMH) es el día en el cual le rendimos un homenaje a los trabajadores humanitarios que han perdido sus vidas y a aquellos que continúan arriesgándola todos los días con el fin de proporcionar ayuda a los necesitados. Este día actualmente es establecido como una celebración global de espíritu humanitario. El 19 de agosto de 2015, se llevará a cabo el VII Encuentro de actores sociales en temas humanitarios, en el marco del Día Mundial Humanitario, en donde se mostraran los avances en investigación y experiencias en el trabajo humanitario, para una comprensión pública mundial, elogiando las acciones ejercidas por aquellos que dedican su vida a la acción humanitaria. Hora: 8:30 am Lugar: Universidad Santo Tomás (Edificio Dr. Angélico, Carrera 9 No. 72 - 90. Aula Magistral 401) ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co -- Juan Carlos Pachón Twitter @Arttesano http://arttesano.com 57-1-3102694942 Skype : arttesano ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
sent from a phone Am 15.08.2015 um 13:50 schrieb Christoph Hormann chris_horm...@gmx.de: The question is how much is actually gained from this when landuse=forest and natural=wood are practically identical anyway and mean the same, namely 'this area is densely covered by trees'. Rendering landcover=trees as well would just further fragment tagging. IMHO it would rather encourage mappers to make more sense out of these than it is now. I'm myself adding a pointless landuse=forest for every landcover=trees now (for the renderer), and I guess most other mappers do the same. I will remove them from non-forests as soon as the landcover tag becomes visible ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
W dniu 15.08.2015 15:23, Martin Koppenhoefer napisał(a): you are mistaken, the motivation for landcover was not connected to the natural (as in nature) and managed idea. Usually the distinction between wood and forest is size and density, the distinction between natural and landuse is about named entities vs. the usage by man attribute. A group of trees in the park is sometimes a wood but never a forest. Landcover has a point besides trees (think grass for instance) I didn't say it was the motivation behind introducing landcover scheme. Wherever it came from and whatever is the difference between wood and the forest, it is a useful scheme in itself, as I wrote - although the higher level of uncertainity, the more useful it become. It is always better to know something exactly than just have a general idea, BUT if you're not sure, it's better to say it clearly than pretend you know better. That's the recipe for a hidden disaster, like spreading entropy in the database and tag definitions. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Trees
On 15/08/15 14:39, Andy Townsend wrote: There's lots of discussion on Openstreetmap-Carto's github about this, which explains what's possible with the standard style right now, but if you're not subject to those restrictions you can certainly render leaf_type now - I've been doing it for my own use for some time (I wrote a diary entry about it a bit back) and it certainly makes areas of trees make more sense on the map. I'm in much the same place at the moment on my own UK rendering. The different types of 'woodland' makes sense around this area. What is iritating is the mass use of 'brown' for farms around Birmingham when in practice the whole area is mainly farmland. I'm just trying to work out how to strip the 'farm yard' from the generic farm tagging so that specific orchard and similar farming activity shows up better. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 2015-08-15 13:15, Serge Wroclawski wrote: On Sat, Aug 15, 2015 at 6:43 AM, Colin Smale colin.sm...@xs4all.nl wrote: So who decides what is good data and what is bad data? The community as a whole decides what is good and bad data. That starts with the local community and moves up to the OSM community as a whole in terms of whether or not data belongs in OSM or not. I disagree here, you are in a dream world. The decision is made on an individual, case-by-case basis by the mapper who exercises his inalienable right to delete or modify data. These decisions are not ratified by the community, but they are discussed to death if anyone happens to notice and takes exception. There is no consensus, there is just one vociferous minority (of the set of all mappers) shouting at another vociferous minority until one party or the other loses the will to live. Should we be working towards creating a consensus, or at least working out a workable definition of consensus? (Actually I think the current malaise is deeper than that - it's an identity crisis) Should we still be saying that the user is free to tag as they see fit? Quote from the wiki: Remember that OpenStreetMap does not have any content restrictions on tags that can be assigned to nodes, ways or areas. You can use ANY TAGS YOU LIKE, but PLEASE DOCUMENT THEM here on the OpenStreetMap wiki, even if self explanatory. (Interestingly, it doesn't mention relations, but I assume this is an oversight.) And visibility on the ground needs nuancing. Are we to remove underground pipelines/power lines? If you were able to go underground, then you'd find such data. But if you can't- how do you know these lines exist? You probably are using a feature that you *can* see without being underground. Good question. We assume they were not entered from sources without a suitable licence. Should we delete them? I certainly don't need to know where the gas pipelines are. Or boundaries? I specifically addressed political boundaries in my previous mail. I was talking about all kinds of boundaries, not just political. Visible and/or verifiable might be better. A rule that needs loads of exceptions, is not a well formed rule. Verifiable and visible are essentially synonymous in this discussion. If that were true, then the existence of an abandoned railway route would effectively be visible by virtue of the fact that it is verifiable. An abandoned railway route IS an abandoned railway route, even today (i.e. that is current data). It WAS a working railway line. That is all verifiable. Yes, but we don't map things that used to be present but are no longer present. A road used to be here but is now a building. We don't map the old road, only what's present now. An abandoned railway route is present now. It may not may not be immediately obvious from a quick look on site. What about roman roads which are no longer visible without remote sensing or ground penetrating radar? Are we suggesting they also have no place in OSM? - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
To clarify, I'm not advocating the use of landcover=* tag (I'm on the fence). However I've never liked that fact that an attribute of tree areas (managed) was differentiated with primary key tags instead of sub-tags such as: landuse/landcover=wood/trees managed=yes/no landcover=trees is already in use so it wont really fragment it further. The unifying of the render doesn't reduce fragmentation either, it just papers over the cracks in tagging inconsistencies. This new rendering, which I support in principle, should not negate the need to sort out these inconsistencies, even if is millions of entities. Cheers Dave F. On 15/08/2015 12:50, Christoph Hormann wrote: The question is how much is actually gained from this when landuse=forest and natural=wood are practically identical anyway and mean the same, namely 'this area is densely covered by trees'. Rendering landcover=trees as well would just further fragment tagging. The suggestion of using landcover=trees is generally based on the idea that both landuse=forest and natural=wood have a distinct meaning and there are tree covered areas which are neither of these. But in reality this is not the case and due to the widespread use of these tags it is likely this will never happen, it would require a systematic re-assessment of millions of features. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
I meant it a bit rhetorically... Let's live and let live, instead of deleting stuff that *we* don't happen to be interested in. Which brings us back to Russ's original point. On 2015-08-15 14:08, Lester Caine wrote: On 15/08/15 12:55, Colin Smale wrote: Good question. We assume they were not entered from sources without a suitable licence. Should we delete them? I certainly don't need to know where the gas pipelines are. But someone buying a house close by may be interested? A number of pipelines have been laid around here and we could have plotted their routes as the various roads were dug up and trenches cut ... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]
W dniu 15.08.2015 13:50, Christoph Hormann napisał(a): The suggestion of using landcover=trees is generally based on the idea that both landuse=forest and natural=wood have a distinct meaning and there are tree covered areas which are neither of these. But in reality this is not the case and due to the widespread use of these tags it is likely this will never happen, it would require a systematic re-assessment of millions of features. In my opinion suggestion of using landcover=trees is based on the lack of clarity of these tags. Forest suggests it is curated somehow (landuse), wood suggests it is not (natural), but nobody is sure anymore what they really mean (see their current definitions!). This is a major problem when widespread tags are source of confusion. However landcover=trees is not a solution for this problem as a whole. It is a generic tagging scheme which holds its position even if we have both major tags clearly defined, because it is for the mappers to tell I don't know what kind of tree area is this exactly and that's why it's really needed. I may even think, that if we have used it from the beginning, we wouldn't have the problem of forest/wood at all. Generic values are important to be as precise as it's possible and prevent people from cheating (especially tagging for renderer). That's why building=yes is so popular and why we have natural=water. I like Dave F. proposition of having cascading tag scheme for all the tree areas very much: landuse/landcover=wood/trees managed=yes/no I hope one day we will have something this elegant. Choosing landuse would overload the meaning of this tag (Land use is the human use of land.) in general, while landcover could be understatement in some cases, so maybe we should use natural (as in water), but let's not get distracted by such nuances in this moment. The message is: it would be very good to have something general for tree areas and whether it would be based on landcover=trees or not, it is the most proper tag to use when in doubt. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] stop deleting abandoned railroads
I realize that I was not clear with my comment. My point is that we cannot resolve this issue by simply deleting data. Former railroads, or for former (historic) streets (as in Roman Street) or former important road routes (like historic Route 66) could best be handled by relations. To take as an example a former railroad route: The relation would comprise of modern streets, agricultural tracks, paths, embankments (even without any path) plus, possibly, buildings (which today in most cases are used in a completely different way or are in ruins) The tagging that is most used (I think) is route=historic historic=railway example: relation 3183397 (my own attempts are not tagged like this - I m going to change them to this style) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
Hi Does the combined wood/forest update include landcover=trees? If not it needs to be included all three should render the same (IMO). Cheers Dave F. On 15/08/2015 03:27, Paul Norman wrote: This email is also in user diary form at osm.org/user/pnorman/diary/35589 where issue numbers are linked. OpenStreetMap Carto 2.33.0 has been released. This release focuses on cartographic style improvements, but the release notes also include 2.32.0. The biggest changes are - A randomized symbology for forests for natural=wood and landuse=forest #1728 #1242 A long time in the works, this improvement has finally landed. The two tags were merged - they are indistinguishable to the data consumer.[1] A randomized symbology was first suggested by SK53[2] at SOTM-EU 2014, and this feature would not have happened without his extensive research, or imagico's tools for creating an irregular but uniformly distributed and periodic dot pattern[3] - Rendering minor roads and service rail later for mid-zoom clarity #1682 #1692 #1676 #1647 As all residential, unclassified, and service roads in a city became mapped the rendered view became over-crowded, bloblike, and difficult to read. - Unification of footway/path and rendering surface of them The mess that is highway=path is well-known[4], and it is necessary to do some kind of processing as a data consumer. A distinction is now made between paved and unpaved footways. - Rendering of Antartic ice sheets from shapefiles #1540 Ice sheets in Antartica are a bit of a special case, and pre-generated shapefiles are now used - Mapnik 3 preperations #1579 The style is not yet fullly tested with Mapnik 3 and we don't claim to support it, but several bugs were fixed. Most of the work was done on the Mapnik side - No longer rendering proposed roads #1663 #1654 - Power area colour adjusted #1680 - Better place label order #1689 - meadow/grassland and orchard/vineyard color unification #1655 - Render educational area borders later #1662 - New POI icons A full list of changes can be found on Github at https://github.com/gravitystorm/openstreetmap-carto/compare/v2.31.0...v2.33.0) [1]: https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52816195 [2]: http://sk53-osm.blogspot.ca/2014/09/woodland-cartography.html [3]: http://www.imagico.de/map/jsdotpattern.php [4]: http://www.openstreetmap.org/user/Richard/diary/20333 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
The woodland change looks much better, but would it not be possible to render broadleaved, needleleaved and mixed using different tree images, as seen on other maps? This would, I think, give people more incentive to add this information when mapping woodland. Regards Tony On 15 August 2015 at 04:27, Paul Norman penor...@mac.com wrote: This email is also in user diary form at osm.org/user/pnorman/diary/35589 where issue numbers are linked. OpenStreetMap Carto 2.33.0 has been released. This release focuses on cartographic style improvements, but the release notes also include 2.32.0. The biggest changes are - A randomized symbology for forests for natural=wood and landuse=forest #1728 #1242 A long time in the works, this improvement has finally landed. The two tags were merged - they are indistinguishable to the data consumer.[1] A randomized symbology was first suggested by SK53[2] at SOTM-EU 2014, and this feature would not have happened without his extensive research, or imagico's tools for creating an irregular but uniformly distributed and periodic dot pattern[3] - Rendering minor roads and service rail later for mid-zoom clarity #1682 #1692 #1676 #1647 As all residential, unclassified, and service roads in a city became mapped the rendered view became over-crowded, bloblike, and difficult to read. - Unification of footway/path and rendering surface of them The mess that is highway=path is well-known[4], and it is necessary to do some kind of processing as a data consumer. A distinction is now made between paved and unpaved footways. - Rendering of Antartic ice sheets from shapefiles #1540 Ice sheets in Antartica are a bit of a special case, and pre-generated shapefiles are now used - Mapnik 3 preperations #1579 The style is not yet fullly tested with Mapnik 3 and we don't claim to support it, but several bugs were fixed. Most of the work was done on the Mapnik side - No longer rendering proposed roads #1663 #1654 - Power area colour adjusted #1680 - Better place label order #1689 - meadow/grassland and orchard/vineyard color unification #1655 - Render educational area borders later #1662 - New POI icons A full list of changes can be found on Github at https://github.com/gravitystorm/openstreetmap-carto/compare/v2.31.0...v2.33.0) [1]: https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52816195 [2]: http://sk53-osm.blogspot.ca/2014/09/woodland-cartography.html [3]: http://www.imagico.de/map/jsdotpattern.php [4]: http://www.openstreetmap.org/user/Richard/diary/20333 ___ 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] stop deleting abandoned railroads
On 15/08/15 12:55, Colin Smale wrote: Good question. We assume they were not entered from sources without a suitable licence. Should we delete them? I certainly don't need to know where the gas pipelines are. But someone buying a house close by may be interested? A number of pipelines have been laid around here and we could have plotted their routes as the various roads were dug up and trenches cut ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone Am 15.08.2015 um 12:31 schrieb Serge Wroclawski emac...@gmail.com: 1. Visible on the ground but difficult to detect (ie require specialized knowledge) or 2. No longer visible at all. no, the second case would be mistagged with railway=abandoned in most of the cases (should be 'razed' or 'dismantled') and the first case (visible on the ground) might need specialized knowledge in some cases and in many others not. cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Trees (was: OpenStreetMap Carto v2.33.0 release)
There's lots of discussion on Openstreetmap-Carto's github about this, which explains what's possible with the standard style right now, but if you're not subject to those restrictions you can certainly render leaf_type now - I've been doing it for my own use for some time (I wrote a diary entry about it a bit back) and it certainly makes areas of trees make more sense on the map. Cheers, Andy (SomeoneElse) Original Message From: tony wroblewski Sent: Saturday, 15 August 2015 12:48 To: Paul Norman Cc: talk@openstreetmap.org; dev Openstreetmap Subject: Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release The woodland change looks much better, but would it not be possible to render broadleaved, needleleaved and mixed using different tree images, as seen on other maps? (snip) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Intégration des numéros de porte
Le 15 août 2015 11:25, Aurélien kinj...@gmail.com a écrit : Bonjour à tous, J'ai remarqué que dans les grandes villes, les numéros des bâtis étaient indiqués partout partout partout et ça c'est super. En revanche dans des villes moyennes comme Dieppe, ils ne sont pas renseignés. Pourquoi ? - Est-ce parce qu'elles ne sont pas disponibles dans la BANO ? - Est-ce que parce que ça demande du temps à les intégrer et personne ne s'en est encore occupé dans ces territoires là ? (il y a des outils pour faciliter leur intégration ou faut-il le faire à la main ?) - Est-ce par un soucis de fiabilité et mieux vaut ne pas les intégrer qu'intégrer des données non fiables ? S'il n'y a pas de raison bloquante, alors j'y prendrai un malin plaisir à les renseigner :) Mais dans ce cas pourriez-vous me guider afin de ne pas faire d'erreur ? Merci pour vos réponses. A bientôt C'est un mix des 3 raisons que tu évoques... - pas toujours disponible, - l'intégration prends du temps (quand on le fait bien, c'est à dire en vérifiant et pas en important rapidement un peu en aveugle) - la fiabilité des données récupérées n'est pas parfaite... donc besoin de contrôler, vérifier, parfois en allant sur le terrain et tout ça prends du temps. Tu peux t'y atteler, cadastre.openstreetmap.fr peut extraire les numéros automatiquement à partir du cadastre, charge à toi ensuite de les vérifier avant de les envoyer vers OSM. Ce qu'il faut éviter c'est un simple download/upload car n'importe quel script pourrait le faire sur la France entière et on a choisit justement de ne pas procéder comme cela car il n'y a aucune valeur ajoutée pour OSM par rapport aux données disponibles via BANO voire via la BAN. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] stop deleting abandoned railroads
On 15/08/15 12:15, Serge Wroclawski wrote: So who decides what is good data and what is bad data? The community as a whole decides what is good and bad data. That starts with the local community and moves up to the OSM community as a whole in terms of whether or not data belongs in OSM or not. The problem is one of terminology. Or rather visibility. The data many of us are looking to use is already in the change logs of the main database. It is managing the continuity of that older data in conjunction with later additions that is the problem. An example link given on this thread showed the break in an old track bed which has been removed, but currently there is no content for the new road which follows the line of that track bed. We have lost data which would have been retained if the relevant section of track bed had been re-tagged as a road ... and the section that was actually removed by the new highway was the only piece actually 'deleted'. Just as micro-mapping has little interest to some users, history is irelevent to others, but that is not 'bad data', but rather data that needs to be managed by a more open consensus that just 'you can't see it delete it'? And visibility on the ground needs nuancing. Are we to remove underground pipelines/power lines? If you were able to go underground, then you'd find such data. But if you can't- how do you know these lines exist? You probably are using a feature that you *can* see without being underground. That more and more companies are using OSM over google as a base layer is fact. The question is perhaps should THEIR data be included in the main database or only accessible as a secondary layer. The points were underground services are accessed need to be mapped on the main database, such as station entrances, or storm water outflow pools, so at what point does third party data become 'mainstream'? Historic material has exactly the same problem ... that some elements are 'currently visible' combines with elements that no longer exist is a a verifiable fact, but either one duplicates the whole lot on an OHM version of the data, or one simply maintains a little more material in the main database. The tagging decides what can be seen for a current rendering rather than snipping out bits which still need to be maintained for an historic one. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
I'm on the fence about this. Does the 'general purpose' mapnik rendering need such distinctions? Would the vast majority of end users really care. Could it even make it more confusing for them? Cheers Dave F. On 15/08/2015 12:45, tony wroblewski wrote: The woodland change looks much better, but would it not be possible to render broadleaved, needleleaved and mixed using different tree images, as seen on other maps? This would, I think, give people more incentive to add this information when mapping woodland. Regards Tony --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On Saturday 15 August 2015, Dave F. wrote: Hi Does the combined wood/forest update include landcover=trees? If not it needs to be included all three should render the same (IMO). The question is how much is actually gained from this when landuse=forest and natural=wood are practically identical anyway and mean the same, namely 'this area is densely covered by trees'. Rendering landcover=trees as well would just further fragment tagging. The suggestion of using landcover=trees is generally based on the idea that both landuse=forest and natural=wood have a distinct meaning and there are tree covered areas which are neither of these. But in reality this is not the case and due to the widespread use of these tags it is likely this will never happen, it would require a systematic re-assessment of millions of features. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone Am 15.08.2015 um 12:31 schrieb Serge Wroclawski emac...@gmail.com: The problem that we have in some parts of the world is a lack of data, but in other parts, we have an abundance of bad imports, and a general timidness around the removal of data that we can't find the owner of, which leaves us with data that *we know is bad*, but where the individual mappers do not feel empowered to act on because of this exact attitude of needing to contact and work with the importer. Being myself mapping in areas where the few bad imports (and also those possibly bad and not discussed beforehand) have been almost instantly reverted, I am often not thinking about imports at all. Yes, you are right, data trash resulting from badly performed imports (or where bad or unsuitable data has been imported) should be cleaned up and can be removed if manual cleanup seems too tedious and the overall quality is below our standard in manually mapped areas. But this is (I hope) not the typical situation in osm besides a few countries, and it is not what this thread is about. Russ started this thread complaining that someone had deleted some railway=abandoned he had surveyed (i.e. something is still there to survey) and added to OSM, and he was suspecting that some people in the community were encouraging such actions by questioning the railway=abandoned tag and telling others to delete stuff they can't _easily_ see (what in turn some mappers interpret as visible from aerials). cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-ja] Fwd: [OSM-dev] OpenStreetMap Carto v2.33.0 release
いいだです。 OSM Cartoの v.2.33.0がリリースされ、osm.orgに適用されました。 今回の更新での大きな変更点は以下のとおりです。 * 森林のレンダリングが統一された landuse=forest と natural=woodの色合いが統一されました。 そのため、京都・神戸・奈良と他の地域の森林地域レンダリングの色合いが異なる、という点が、 少なくともレンダリングの観点からは解消されました。 * pathとfootwayのレンダリング統一 pathのレンダリングが、footwayの色合いとなりました。 今後は、surfaceタグの有無でレンダリングが変更となります。 その他、いくつものPOI追加などが行われています。 お住いの地域・これまで編集した地域をチェックしてみてくださいませ。 (配信のキャッシュの影響で変更されない場合もありますが、そろそろ広まりつつあるようです) -- Forwarded message -- From: Paul Norman penor...@mac.com Date: 2015-08-15 11:27 GMT+09:00 Subject: [OSM-dev] OpenStreetMap Carto v2.33.0 release To: t...@openstreetmap.org, dev Openstreetmap d...@openstreetmap.org This email is also in user diary form at osm.org/user/pnorman/diary/35589 where issue numbers are linked. OpenStreetMap Carto 2.33.0 has been released. This release focuses on cartographic style improvements, but the release notes also include 2.32.0. The biggest changes are - A randomized symbology for forests for natural=wood and landuse=forest #1728 #1242 A long time in the works, this improvement has finally landed. The two tags were merged - they are indistinguishable to the data consumer.[1] A randomized symbology was first suggested by SK53[2] at SOTM-EU 2014, and this feature would not have happened without his extensive research, or imagico's tools for creating an irregular but uniformly distributed and periodic dot pattern[3] - Rendering minor roads and service rail later for mid-zoom clarity #1682 #1692 #1676 #1647 As all residential, unclassified, and service roads in a city became mapped the rendered view became over-crowded, bloblike, and difficult to read. - Unification of footway/path and rendering surface of them The mess that is highway=path is well-known[4], and it is necessary to do some kind of processing as a data consumer. A distinction is now made between paved and unpaved footways. - Rendering of Antartic ice sheets from shapefiles #1540 Ice sheets in Antartica are a bit of a special case, and pre-generated shapefiles are now used - Mapnik 3 preperations #1579 The style is not yet fullly tested with Mapnik 3 and we don't claim to support it, but several bugs were fixed. Most of the work was done on the Mapnik side - No longer rendering proposed roads #1663 #1654 - Power area colour adjusted #1680 - Better place label order #1689 - meadow/grassland and orchard/vineyard color unification #1655 - Render educational area borders later #1662 - New POI icons A full list of changes can be found on Github at https://github.com/gravitystorm/openstreetmap-carto/compare/v2.31.0...v2.33.0 ) [1]: https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52816195 [2]: http://sk53-osm.blogspot.ca/2014/09/woodland-cartography.html [3]: http://www.imagico.de/map/jsdotpattern.php [4]: http://www.openstreetmap.org/user/Richard/diary/20333 ___ dev mailing list d...@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone Am 15.08.2015 um 13:55 schrieb Colin Smale colin.sm...@xs4all.nl: What about roman roads which are no longer visible without remote sensing or ground penetrating radar? Are we suggesting they also have no place in OSM? actually I am living in an area with a lot of ancient roman roads, even if most of them are now covered by modern roman roads (roads tend to remain on the same place if it was originally chosen well, what is typically the case for ancient roman (and other like etruscan) roads), there are some spots where the old paving comes to light (often on purpose with an educational / exemplary motivation), one infamous example is a cycleway I used to take, where the roman paving (for 2 meters or so) was a major nuisance ;-). --- for sure they don't dare to try this on a road. To make it short: I only tag those parts of ancient roman roads as such, which can still be recognized as roman road (i.e. ancient paving still present). Btw: I don't find the tagging historic=roman_road particularly well chosen. Shall we use a different value for every ancient culture that built roads? IMHO not, I suggest to use historic=road together with historic:civilization=* for ancient roads (currently used 10 times fewer). See here for current geographical distribution of this tag: http://taginfo.openstreetmap.org/tags/historic=roman_road#map On the other hand, I do add old_name tags to objects if I am aware of it, despite the fact that you mostly won't find them on the literal ground (but they are of course verifiable by anyone who seriously tries to). cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]
sent from a phone Am 15.08.2015 um 14:58 schrieb Daniel Koć daniel@koć.pl: In my opinion suggestion of using landcover=trees is based on the lack of clarity of these tags. Forest suggests it is curated somehow (landuse), wood suggests it is not (natural), but nobody is sure anymore what they really mean (see their current definitions!). This is a major problem when widespread tags are source of confusion. However landcover=trees is not a solution for this problem as a whole. you are mistaken, the motivation for landcover was not connected to the natural (as in nature) and managed idea. Usually the distinction between wood and forest is size and density, the distinction between natural and landuse is about named entities vs. the usage by man attribute. A group of trees in the park is sometimes a wood but never a forest. Landcover has a point besides trees (think grass for instance) cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-ja] 8/22 開催。京都世界遺産マッピングパーティ：第５回上賀茂神社
京都の山下です。皆さんこんにちわ。 京都世界遺産マッピングパーティ 第５回上賀茂神社はいよいよ来週、8/22 です。 皆さんどうぞお越しください！！ // ９月以降の日程、ターゲットをちょこちょこ調整しています。 // ご確認ください In message 20150722.235933.01376017.yasun...@yamasita.jp yasun...@yamasita.jp writes 京都の山下です。皆さんこんにちわ。 京都の世界遺産を毎月一か所ずつターゲットにして、 楽しみながら 自由な地図である OpenStreetMap に書いていく マッピングパーティ、第５回は上賀茂神社をターゲットにして 8/22 に開催します https://openstreetmap.doorkeeper.jp/events/28687 皆さんのご参加をお待ちしています！！ -- 山下康成＠京都府向日市 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] Best base to build on ...
On 15 August 2015 at 17:14, Lester Caine les...@lsces.co.uk wrote: The obvious question is that given tilemill is not longer being maintained, what are the preferred alternatives? Depending on what you need exactly, Kosmtik might be an alternative: https://github.com/kosmtik/kosmtik -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
W dniu 15.08.2015 15:16, Martin Koppenhoefer napisał(a): IMHO it would rather encourage mappers to make more sense out of these than it is now. I'm myself adding a pointless landuse=forest for every landcover=trees now (for the renderer), and I guess most other mappers do the same. I will remove them from non-forests as soon as the landcover tag becomes visible I asked about it here: https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817 but the issue is closed now without too detailed discussion. I guess we should at least create specific Wiki page to document it and try to define how it should be used, but I had no time to touch it and nobody else did it too. I think after that I can open simple PR, so we can discuss it in detail. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Best base to build on ...
Not getting much help on the GB list so I thought I'd widen the question. A couple of years back I had my own server setup working with a base of OSRM and routing covering the UK. While the map server is still working, routing has packed up and some of the alternate base maps are no longer accessible. Given that the OSM styling is going to switch to something which in my book is unacceptable I needed to sort my own rendering as a base for UK usages. I've got tilemill running finally with a few niggles, but I've actually managed to switch some style elements to be more UK frindly using darker road colours. But as yet I've not got the routing side working again. The obvious question is that given tilemill is not longer being maintained, what are the preferred alternatives? I'm actually not happy with the way OSRM has moved and there does not seem to be a 'standard' for the support structure? Each section seems to need a different set of tool versions. I'm happy to have to use postgresql despite having had two corruptions already, but mysql has no place here. My main stack is Nginx, PHP and Firebird and I have tilemill running on top of that, and the planet file is being replicated nicely. So do I spend a lot more time on tilemill, or am I better switching before spending too much more time on that, and what other options are available to replace OSRM. OSMAND is working well for me in the car so is that perhaps a better use of time given that I still have a time hungry support service to provide ... and I still need OHM as an option ... I need to get this machine configured before shipping over to the data centre where it will sit on a high speed pipe so I need to get it right. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
Hi I think that discussion should have been titled Stop tagging natural=wood and landuse=forest differently. As I've said have a unified render just covers up that we're tagging incorrectly. There should only be one primary tag to describe large area of trees. Whether it be landcover or landuse or whatever, I'm not that concerned about but it really should only be one option. Cheers Dave F. On 15/08/2015 16:13, Daniel Koć wrote: W dniu 15.08.2015 15:16, Martin Koppenhoefer napisał(a): IMHO it would rather encourage mappers to make more sense out of these than it is now. I'm myself adding a pointless landuse=forest for every landcover=trees now (for the renderer), and I guess most other mappers do the same. I will remove them from non-forests as soon as the landcover tag becomes visible I asked about it here: https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817 but the issue is closed now without too detailed discussion. I guess we should at least create specific Wiki page to document it and try to define how it should be used, but I had no time to touch it and nobody else did it too. I think after that I can open simple PR, so we can discuss it in detail. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Taginfo update
Hi! Taginfo hat die Woche ein Update bekommen. Zusammen mit Christopher Baines habe ich an der Mobil-Fähigkeit der Webseite gearbeitet. Einige Bugs wurden gefixt und einige Abfragen, die sehr langsam waren, sind jetzt sehr schnell. Aber die größten Neuigkeiten betreffen das neue Taglist-Feature: Taginfo kann jetzt automatisch die Tag-Tabellen erzeugen, die man überall im Wiki sieht. Unter http://wiki.openstreetmap.org/wiki/Taginfo/Taglists gibts dazu Erklärungen. Dies sollte sehr nützlich sein, die manuelle Arbeit im Wiki zu reduzieren. Ausprobieren wie immer unter: https://taginfo.openstreetmap.org/ Mehr Details in meinem Blog unter http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Taginfo updates
Hi! Taginfo got an update this week. Together with Cristopher Baines I worked on making it a bit more mobile friendly. Some bugs were fixed and some parts that were rather slow are much faster now. But the biggest news is the new taglist feature: Taginfo can now automatically generate the tags tables you see all over the OSM wiki. See http://wiki.openstreetmap.org/wiki/Taginfo/Taglists for how this works. This should be very useful to reduce the manual work needed for updating the wiki. Try it out at: https://taginfo.openstreetmap.org/ Details about all of this at: http://blog.jochentopf.com/2015-08-15-hacking-on-taginfo.html Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
Warin writes: On 15/08/2015 3:46 PM, Russ Nelson wrote: Railway=dismantled. Doesn't get rendered except where it should be, do you still want railway=disused to remain? Are we even talking about the same thing? Let's assume that you made a s mple t po. Don't those last two words look a little weird with missing bits? Shouldn't those letters be there? Shouldn't the dismantled bits of a railroad be in OSM as dismantled bits? Lookit, I'm also a fan of unfinished railroads. http://russnelson.com/unfinished-railroads.html You don't see me insisting that the unbuilt sections of these railroads get mapped, do you? No, because they never existed, and you can't see any evidence that they did. With a built, operated railroad, you *can* see evidence that they did, even if it's only because you can look left and see evidence of the railroad, and you can look right and see evidence of the railroad. Should they NOT be mapped through the farmer's field where they have been plowed into dismantlement? Now, I'm sure somebody will, at some point say, Russell, just go off to OpenHistoricalMap and put your data there. That's fine, except for those pesky implementation details where THEY ARE IN TWO DISPARATE DATABASES, UNCONNECTED. How, exactly, do you make a relation that shows the entire route of a railroad when half of it is off in a different corner? I don't understand why we're having this argument. We map tons of things that you can't see. Why not map as dismantled railroads that have been dismantled? Why not make an exception to the Delete it if you don't see it guideline? It's only a small handful of people who are deleting and counseling deletion of dismantled railways. They are pushing a rigid, mechanistic, inconsistent view of what to map. If we can simply tell them dismantled railways are cool, we love them, deal with it then we'll be done here. I WILL BE HAPPY AND GO AWAY WITH AN EXCEPTION. Don't you want me to be happy? Don't you want me to go away? -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
Serge Wroclawski writes: Our project's policy thusfar has been in contrast to other projects in that each and every one of us is empowered to make changes to anything we see. You're starting to understand! You should make changes to things you see. Things you don't see require a higher standard of knowledge. This leaves our project with a problem of lots of data and no one feeling empowered to remove it. Seriously? THIS is your line of reasoning? There's a simple way to empower them: If it's got TIGER tags and you don't see it, delete it. Done. Next problem. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] stop deleting abandoned railroads
On 15/08/15 16:29, Russ Nelson wrote: Now, I'm sure somebody will, at some point say, Russell, just go off to OpenHistoricalMap and put your data there. That's fine, except for those pesky implementation details where THEY ARE IN TWO DISPARATE DATABASES, UNCONNECTED. How, exactly, do you make a relation that shows the entire route of a railroad when half of it is off in a different corner? And it's not just railroads that this affects ... In my book OHM needs to be a clone of OSM AND all the history so that we can manage things properly. But the bulk of the missing historic data IS start_date for every object currently documented, and that then needs passing back to OSM. So why not just have the one database? The alternative is a model that CAN use multiple databases, but I think that only really works for secondary data? Trying to merge geometry is not something that works well unless that geometry can be completely isolated. Trying to use the same way elements for different objects in different databases does not work :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
On 15/08/15 16:31, Dave F. wrote: Whether it be landcover or landuse or whatever, I'm not that concerned about but it really should only be one option. I think that there is a European definition for 'landuse' as part of the standards? Certainly the documentation I have for the NLPG database provides a clean set of tags for the use of parcels of land. This is the 'Basic Land and Property Unit' BLPU Classification, but I'm not sure where https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/11493%2F144275.pdf fits in today ... that also links to the Eurosat LUCAS classifications. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-uy] Definición de localidades
Si superpones el shp rural, el hueco de la localidad de 33 queda definiendo el limite de 33 y villa sara. A efectos practicos lo comento. El 11/08/2015 10:23, aml...@adinet.com.uy aml...@adinet.com.uy escribió: Estimados: dado que tenemos algunos problemitas de definición de límites de localidades según las fuentes usadas del INE y de que Catastro esta publicando shp de todo el pais de las localidades actualizadas, planteo sería correcto usar estas nuevas fuentes como definición de localidades. Ej: ciudad de Treinta y Tres esta partida en dos segíun el INE, ciudad de Treinta y Tres y una localidad ficta llamada Ejido de Treinta y tres, (cosa que confunde a los usuarios) esta debe desaparecer y fusionar las dos areas, para que se adecue a la realidad. Algunas localidades estan en proceso de actualización en catastro y se me informó estarían a fin de año, no se si será cierto. Poniendo énfasis, en que Catastro es la autoridad en esta información y su mantenimiento y que ahora entró en una etapa de compartir datos, les dejo la inquietud y vemos que hacemos. saludos ___ Talk-uy mailing list Talk-uy@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-uy ___ Talk-uy mailing list Talk-uy@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-uy
[Talk-cat] Com fer un mapa personalitzat?
Bona tarda a tots, com es pot fer un mapa on visualitzar algunes etiquetes concretes que en els mapes habituals no surten? Per exemple llocs on hi hagi wifi gratis. Algo similar a la web http://www.osmhydrant.org/ on es visualitzen els hidrants i les estacions de bombers. Moltes gràcies per l'ajuda! Fermí ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Am 14.08.2015 um 14:00 schrieb Flaimo: Hallo, Erklär das bitte im Detail. Wieso sollte es programmatisch nicht feststellbar sein, dass Schienen auf der Straße liegen, wenn sie die gleiche explizite oder implizite Layer-Angabe besitzen und die gleichen Nodes haben? Das gilt nur für den Fall, dass die Ways exakt gleich bleiben, und die Gleise nicht extra gemappt werden. Sobald jemand die Gleise extra mappt, ist es nicht mehr feststellbar. Also jetzt mal in eigene Ways - und irgendwer trennt danach die Gleise in die Fahrtrichtungen auf, mit dem Argument wenn schon, dann richtig. Klingt für mich nach Salamitaktik - dagegen. Ich denke, dass das sehr wohl möglich ist. Sogar der JOSM-Validator erkennt bereits jetzt übereinanderliegende Ways und deren Nodes, wenn sie zum Beispiel keine Tags besitzen. Sogar Wege die den gleichen Layer haben und sich ohne Node kreuzen erkennt er. Somit denke ich, dass dein Hauptargument bereits widerlegt ist. Auch erinnere ich an den Vorteil des nichtvorhandensein des Layer-Konzepts klassischer GIS in OSM - wenn wir mit bei zwei übereinanderliegenden Ways anfangen, öffnen wir die Kiste der Pandora. flaimo lg, Michael -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] landcover=trees
On 8/15/2015 8:13 AM, Daniel Koć wrote: I asked about it here: https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817 but the issue is closed now without too detailed discussion The issue was closed because it was solved - the rendering was unified. The topic of that issue was not landcover=trees. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Best base to build on ...
On 15/08/15 18:18, nebulon42 wrote: I'm not sure how TileMill fits within your rendering stack here. Do you mean Mapnik? tilemill allows me to serve tiles and play with the tile sheets and I have it working via nginx as well. If you talk about carto-based style development the best alternative for TileMill right now is Kosmtik (https://github.com/kosmtik/kosmtik), which is developed and maintained by Yohan Boniface. Some if not all of the maintainers of osm-carto use it. I have also switched from TileMill to Kosmtik for my work on osm-carto a few months ago. It is addressing the more tech-savvy kind of style developers (more command-line stuff), but the switch has also optimized my workflow. Will have a look, but it seems to just another sticking plaster rather than a well planned development base :( Not succeeded in installing this yet - problem posted on github ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On 8/15/2015 4:45 AM, tony wroblewski wrote: The woodland change looks much better, but would it not be possible to render broadleaved, needleleaved and mixed using different tree images, as seen on other maps? Not at the moment. See https://github.com/gravitystorm/openstreetmap-carto/issues/822 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Best base to build on ...
On 8/15/2015 8:14 AM, Lester Caine wrote: Not getting much help on the GB list so I thought I'd widen the question. A couple of years back I had my own server setup working with a base of OSRM and routing covering the UK. While the map server is still working, routing has packed up and some of the alternate base maps are no longer accessible. ... The obvious question is that given tilemill is not longer being maintained, what are the preferred alternatives? Kosmtik is the preferred alternative to Tilemill, but both of these are style design programs, not programs for serving tiles to others. I have no doubt that you could proxy them via a caching proxy, but this is a horrible idea. Use any one of the standard tile rendering servers like renderd+mod_tile or tirex+mod_tile. If you don't need update support (which you don't if you were considering Tilemill) then mapproxy, tilestash, tilecache, and non-OSM specific options are available. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
sent from a phone Am 15.08.2015 um 17:31 schrieb Dave F. dave...@madasafish.com: As I've said have a unified render just covers up that we're tagging incorrectly. There should only be one primary tag to describe large area of trees. Whether it be landcover or landuse or whatever, I'm not that concerned about but it really should only be one option. why should there be just one tag for all kinds of forests and other areas where trees grow? Having a lot of forest with a proper name is very common in some areas and having them grouped into bigger areas of forest, with another name is common as well. And those might be grouped into even bigger areas of forest, with yet another name. My idea is to use the natural key for these pieces of forest with a name (they might also comprise areas which aren't actually tree covered, like a meadow or a lake). If you just put overlapping/nested areas with the name and not the info that it's for/from a forest, you loose something. Then there are areas dedicated to growing trees, but sometimes there aren't actual trees there for the moment (e.g. trees have just been logged, or there was a fire, etc.). This is what I would use landuse=forest for. And then there are areas where actually trees grow, sometimes in a forest and sometimes elsewhere. That's where landcover trees seems appropriate for me. For rendering purposes, I would use a fill mainly for the landcover, while the names (and no fill) would come from natural. Landuse would be mainly for specialist maps, but of course this is up to the rendering style devs to ultimately decide. cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
On 8/15/2015 4:26 AM, Dave F. wrote: Hi Does the combined wood/forest update include landcover=trees? If not it needs to be included all three should render the same (IMO). No. Nor are there any issues created about rendering landcover=trees. As the landcover key is currently not in the database, it is not happening in the short-term either. For clarity, this is not to imply that we will or will not render landcover=trees. As there's no issue about it, it hasn't been discussed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
W dniu 15.08.2015 21:42, Paul Norman napisał(a): On 8/15/2015 8:13 AM, Daniel Koć wrote: I asked about it here: https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817 but the issue is closed now without too detailed discussion The issue was closed because it was solved - the rendering was unified. The topic of that issue was not landcover=trees. Thanks for clarification, Paul - that's exactly what I suspected, but it was pure observation with no guessing implied. I just felt it was the best moment to talk about it on OSM lists before trying anything more with the rendering, because tree area problem is pretty complicated, as we all know. -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
Saturday 15 August 2015 12:59:55, Paul Norman: On 8/15/2015 4:26 AM, Dave F. wrote: Hi Does the combined wood/forest update include landcover=trees? If not it needs to be included all three should render the same (IMO). No. Nor are there any issues created about rendering landcover=trees. As the landcover key is currently not in the database, it is not happening in the short-term either. https://taginfo.openstreetmap.org/keys/landcover 17 117 occurences is not 'not in the database'. Sure, it's only 0.12% of all landuses, but this is a key that isn't even rendered on the default style. For clarity, this is not to imply that we will or will not render landcover=trees. As there's no issue about it, it hasn't been discussed. -- The field from of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release
Please, remember to change the subject when the subject shift occurs... W dniu 15.08.2015 22:15, Ruben Maes napisał(a): 17 117 occurences is not 'not in the database'. Sure, it's only 0.12% of all landuses, but this is a key that isn't even rendered on the default style. Paul was talking about the database which is available to default installation of osm-carto. We plan to update its scheme one day, because many different issues depend on this, but currently it's just a work in progress: https://github.com/gravitystorm/openstreetmap-carto/issues/1504 https://github.com/gravitystorm/openstreetmap-carto/issues/1286 -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] landcover=trees
On 15/08/15 20:59, Martin Koppenhoefer wrote: For rendering purposes, I would use a fill mainly for the landcover, while the names (and no fill) would come from natural. Landuse would be mainly for specialist maps, but of course this is up to the rendering style devs to ultimately decide. Having been investigating the 'farmland' problem ... and it is a PROBLEM ... I would tend to agree with that. The local blocks of farmland are a conglomeration of landcover and changing sections to the ACTUAL cover is going to be difficult. I do need to delete major blocks, but putting them back is even harder work. The areas not 'block mapped' have all of the field structure in place, but no 'farmland' boundary while the directly adjacent areas have multipolygon structures which can not be easily isolated to add all the fine detail of field boundaries. My quick fix for any new rendering is simply to switch off 'farmland' so that the tree blocks it masks actually display. http://www.openstreetmap.org/way/245442613 is an example of the problem, as are the adjacent areas to the right, while to the left the brown areas are the local farm yards and the majority of the remaining cover is farmland. trying to fill that with blocks of landcover is what seems wrong here ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
