Re: [OSM-talk] 'Allowed data'
Russ Nelson wrote: Which is exactly why the 'start_date' and 'end_date' become important elements. Rather than simply wiping those historic layers they get an end date, and the editors simply ignore them unless one has enabled a date range. This then replaces simply deleting perfectly good data and instead hides it away properly. The original proposal was that this data would get moved off to OHM, but that simply does not work when the bulk of the surrounding data is still required from the OSM version. Yeah, OHM doesn't work, not when railbeds get reused as hiking trails, as some of the Dunderberg railbeds have been, and when the trail gets rerouted onto railbed, as the R-D trail has been. I was looking for railbed off the trail, and found old Red Dot blazes instead. As a simple starting point, it is a fact that much of current history is being mapped and then destroyed! I have been adding roundabouts and new housing developments which involve 'moving' roads that already exist and renaming them. In these instances we have the historic versions already recorded ... just no means of tagging the older versions with the real facts? Some people have no interest in even adding buildings to the data, but as a first step I'm talking about simply retaining the data that we are NOW gathering. I don't think it's unreasonable to guess that 99.9% of that data only needs a start date to then be a complete historic record? YES a small percentage of material is a lot more complex, and developments get started, and evolve beyond what was originally planned, or abandoned. That material may well be a candidate for OHM? Yes once one digs deeper into the life of an object there is a lot more history each element of which needs start and stop dates, and my own 'day job' involves that fine detail, where essentially every 'tag' has a created, start end date. In a hundred years time the current view of OSM will be history, both because data has yet to be recorded, but also because that data has evolved, and it is simply recording that evolution correctly which needs to start now. There are people who will want to add the history going backwards, and that is just another aspect, but it only requires that the mechanisms are in place to correctly manage the data going forward? The existing data is already an historic record if only we could get at it easier? -- 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] 'Allowed data'
Joseph R. Justice wrote: On Fri, Dec 6, 2013 at 10:56 PM, Russ Nelson nel...@crynwr.com mailto:nel...@crynwr.com wrote: Andy Street writes: Was the building first opened on that date? or was it when the pub began trading? My main use of start_date and end_date would be for railroads, and even that isn't sufficient, because some railroads were built, used, ripped up, and laid down again, and then ripped up again. How would that be tagged? start_date, end_date, start_date_1, end_date_1? Head asplode! The first obvious solution to that would be to create two entities in the database which just happen to coincide, and which should probably be linked somehow. One entity would be for the land, the physical ground underlying the railway, and would represent the land easement for the railroad, the physical location. The other entity would be for the actual tracks in the ground, the rails and ties and switches and the like, setting on top of and supported by the physical land easement. It would make sense for the entity representing the tracks in the ground to link back to the entity representing the physical ground, the land easement. (The tracks cannot be there, or at least not usefully there, without the land easement for them to rest on.) It might or might not make sense to link the other way; in the example you suggest, should the land easement continue to link to tracks which have been ripped up and are not physically present any more? (Does or should an entity in such a status remain in the database?) I'm certainly not going to say this is and must be the correct way to handle this situation; it's first quick thoughts concerning the issue and how to resolve it and as such might be horribly incorrect given more knowledge of the database and all. But, at least to this naive and ignorant person, it's not obviously and completely and immediately apparent to be wrong, at least at a first surface look. Certainly where roads are rerouted they can either be dragged from their existing path to the new location, but my point is exactly that the information that there HAS been a change of route is as important as the fact that it changed on a certain date. It's modelling this information that is missing currently and while some people would rather simply wipe the prior route out of the history books, even just moving that already mapped information to OHM requires a little more consideration. Delete is simply not a valid concept unless the object never existed in the first place? -- 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] 'Allowed data'
Martin Koppenhoefer wrote: 2013/12/7 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Delete is simply not a valid concept unless the object never existed in the first place? While I find this concept appealing at first glance, it would raise complexity much more if we not only had present but also past objects in the db. We had a mapper in Germany (Mirko) who has mapped underground installations and old road infrastructure in that area that afterwards has been restructured. The density of objects (namely a second system of ways that wasn't in any way correlated to the current ground) made editing in this area much more difficult than without these objects. If we want to be the map for everybody we also have to take care that complexity remains on a level that you can contribute even if you are not a full-time mapper or have studied OSM 1+2 at college ;-) Which is exactly why the 'start_date' and 'end_date' become important elements. Rather than simply wiping those historic layers they get an end date, and the editors simply ignore them unless one has enabled a date range. This then replaces simply deleting perfectly good data and instead hides it away properly. The original proposal was that this data would get moved off to OHM, but that simply does not work when the bulk of the surrounding data is still required from the OSM version. I can see the 'need' to plot things like war campaigns on a second database, but the sort of historic data we are talking about here on the whole is closely linked with the rest of the live data and creating a 'date' slider to display an area over time would require a complete copy of the main database anyway? -- 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] 'Allowed data'
Lester Caine writes: Martin Koppenhoefer wrote: 2013/12/7 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Delete is simply not a valid concept unless the object never existed in the first place? And maybe not even then. I've been working on the Dunderberg Spiral Railway, which is an unfinished railroad built on the side of Dunderberg Mountain just south of Bear Mountain Bridge on the Hudson. The most awesome thing is that you can see a BUNCH of the railbed on the Bing Aerial photos, if you know what you're looking at and for. About 65% of the railway was graded before they gave up. The difficulty is making sense of the bits that were actually constructed -- how do they fit into the design of a continuous ten mile loop of railroad going up in two inclines, then curving around the mountain twice, then back and forth four times. Without mapping the unbilt portions, it's quite difficult to make sense of the bits and pieces of railbed that were built. The only difficulty is how to tag an unfinished railway. I tried railway=unfinished, but NE2 helpfully changed it all to railway=abandoned. While I find this concept appealing at first glance, it would raise complexity much more if we not only had present but also past objects in the db. There is room for a LOT of things in the database that you don't want to see when you're editing. For example, power lines, or boundaries. Sounds like you want to filter out anything with an end_date tag. Which is exactly why the 'start_date' and 'end_date' become important elements. Rather than simply wiping those historic layers they get an end date, and the editors simply ignore them unless one has enabled a date range. This then replaces simply deleting perfectly good data and instead hides it away properly. The original proposal was that this data would get moved off to OHM, but that simply does not work when the bulk of the surrounding data is still required from the OSM version. Yeah, OHM doesn't work, not when railbeds get reused as hiking trails, as some of the Dunderberg railbeds have been, and when the trail gets rerouted onto railbed, as the R-D trail has been. I was looking for railbed off the trail, and found old Red Dot blazes instead. -- --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] 'Allowed data'
Andy Street writes: The start_date is the date that it feature came into existence not the date it was mapped so automatically populating it will just lead to junk data that is indistinguishable from the real valid data. Yeah, seriously! Was the building first opened on that date? or was it when the pub began trading? My main use of start_date and end_date would be for railroads, and even that isn't sufficient, because some railroads were built, used, ripped up, and laid down again, and then ripped up again. How would that be tagged? start_date, end_date, start_date_1, end_date_1? Head asplode! -- --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] 'Allowed data'
On Fri, Dec 6, 2013 at 10:56 PM, Russ Nelson nel...@crynwr.com wrote: Andy Street writes: Was the building first opened on that date? or was it when the pub began trading? My main use of start_date and end_date would be for railroads, and even that isn't sufficient, because some railroads were built, used, ripped up, and laid down again, and then ripped up again. How would that be tagged? start_date, end_date, start_date_1, end_date_1? Head asplode! The first obvious solution to that would be to create two entities in the database which just happen to coincide, and which should probably be linked somehow. One entity would be for the land, the physical ground underlying the railway, and would represent the land easement for the railroad, the physical location. The other entity would be for the actual tracks in the ground, the rails and ties and switches and the like, setting on top of and supported by the physical land easement. It would make sense for the entity representing the tracks in the ground to link back to the entity representing the physical ground, the land easement. (The tracks cannot be there, or at least not usefully there, without the land easement for them to rest on.) It might or might not make sense to link the other way; in the example you suggest, should the land easement continue to link to tracks which have been ripped up and are not physically present any more? (Does or should an entity in such a status remain in the database?) I'm certainly not going to say this is and must be the correct way to handle this situation; it's first quick thoughts concerning the issue and how to resolve it and as such might be horribly incorrect given more knowledge of the database and all. But, at least to this naive and ignorant person, it's not obviously and completely and immediately apparent to be wrong, at least at a first surface look. Joseph ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
As a result of some miss communication I stopped reading the email before the wall of text ended. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
2013/12/5 Lester Caine les...@lsces.co.uk I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. If you are refering to changesets or version timestamps then you are a lucky man, because this is already done. Every single version of every single osmobject has a precise timestamp with not only date but also hours, minutes and seconds. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Martin Koppenhoefer wrote: I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. I am referring to using 'start_date' is it is currently documented http://wiki.openstreetmap.org/wiki/Key:start_date At a very minimum putting a current timestamp in will give a starting point since we know it is valid today, although a future start date is also possible. It is creating the habit of populating it and encouraging the addition where it is known. end_date is only required when an existing object is removed from the data. If you are refering to changesets or version timestamps then you are a lucky man, because this is already done. Every single version of every single osmobject has a precise timestamp with not only date but also hours, minutes and seconds. That is a completely different set of data ;) And since elaboration seems to be required. The history of the way data is created is not the same as the history of how an object came into existence. -- 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] 'Allowed data'
On Thu, 05 Dec 2013 15:20:58 + Lester Caine les...@lsces.co.uk wrote: Martin Koppenhoefer wrote: I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. I am referring to using 'start_date' is it is currently documented http://wiki.openstreetmap.org/wiki/Key:start_date At a very minimum putting a current timestamp in will give a starting point since we know it is valid today, although a future start date is also possible. It is creating the habit of populating it and encouraging the addition where it is known. The start_date is the date that it feature came into existence not the date it was mapped so automatically populating it will just lead to junk data that is indistinguishable from the real valid data. What you really asking for is an auto-generated start_date_sometime_before tag but that data is already logged in the changesets. There is also the matter of *what* started. Take the following example: building=yes amenity=pub name=The Mappers Rest start_date=2013-11-15 Was the building first opened on that date? or was it when the pub began trading? Perhaps that was when the name changed? To do this properly you'll need to automatically add a start_date_sometime_before tag for every tag in the database! -- Regards, Andy Street ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Andy Street wrote: On Thu, 05 Dec 2013 15:20:58 + Lester Caine les...@lsces.co.uk wrote: Martin Koppenhoefer wrote: I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. I am referring to using 'start_date' is it is currently documented http://wiki.openstreetmap.org/wiki/Key:start_date At a very minimum putting a current timestamp in will give a starting point since we know it is valid today, although a future start date is also possible. It is creating the habit of populating it and encouraging the addition where it is known. The start_date is the date that it feature came into existence not the date it was mapped so automatically populating it will just lead to junk data that is indistinguishable from the real valid data. What you really asking for is an auto-generated start_date_sometime_before tag but that data is already logged in the changesets. There is also the matter of *what* started. Take the following example: building=yes amenity=pub name=The Mappers Rest start_date=2013-11-15 Was the building first opened on that date? or was it when the pub began trading? Perhaps that was when the name changed? To do this properly you'll need to automatically add a start_date_sometime_before tag for every tag in the database! Changes to details on the object would be covered by the changelog entries. At this stage simply a date that physical building came into existence would be nice. That only the current view of the object is provided is what 'The Data' is designed to supply, and in this instance the start_date is when the building physically appeared ... You are perfectly correct that there are more start_dates needed, but starting today, any information change such as 'The Mapper Rest'-'The Mappers Arms' would be fairly accurate using the changelog dates. When it is scheduled to change at a future date, we have no means of recording that data. 'The Data' does not do history even if it relates to live data? We have to make those changes in real time rather than relying on the API serving the time correct view! -- 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] 'Allowed data'
2013/12/5 Lester Caine les...@lsces.co.uk You are perfectly correct that there are more start_dates needed, If you have one object for the pub and one for the house you don't have this problem. A building ideally wouldn't have tags like amenity=pub, but of course it does currently in the osm database. When you come to add a tag like start_date or wikipedia or name it would be better to detach the building's occupant from the building object, while for a few tags like architect this might not be necessary. For a POI occupying the whole building you can add a detached node inside the building, or create a multipolygon-relation with the building outline as outer member. I wouldn't suggest overlapping ways as they are really a pita, and I also don't like the POI being part of the building outline because it adds one node to the building as well which is really not needed, and it remains unclear if the POI is outside or inside. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
