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 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
On Sat, Aug 15, 2015 at 5:19 AM, 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. > > 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] 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 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 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] 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 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: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
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] 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] stop deleting abandoned railroads
On 2015-08-15 13:15, Serge Wroclawski wrote: > On Sat, Aug 15, 2015 at 6:43 AM, Colin Smale 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] stop deleting abandoned railroads
sent from a phone > Am 15.08.2015 um 12:31 schrieb Serge Wroclawski : > > 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
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 : > > 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
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
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone > Am 15.08.2015 um 13:55 schrieb Colin Smale : > > 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] OpenStreetMap Carto v2.33.0 release
sent from a phone > Am 15.08.2015 um 13:50 schrieb Christoph Hormann : > > 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 [was Re: OpenStreetMap Carto v2.33.0 release]
sent from a phone
> Am 15.08.2015 um 14:58 schrieb Daniel Koć :
>
> 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
[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
[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] 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] 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] 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] 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
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
[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] Best base to build on ...
On 15 August 2015 at 17:14, Lester Caine 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] OpenStreetMap Carto v2.33.0 release
On 15 August 2015 14:16:06 GMT+01:00, Martin Koppenhoefer 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: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]
On 15 August 2015 14:23:09 GMT+01:00, Martin Koppenhoefer 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] 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. : > > 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
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] 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 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: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
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
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] 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] 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] 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
