Re: [OSM-talk] Admin borders/separate database
On 11/11/2013 03:27 AM, nicholas.g.lawre...@tmr.qld.gov.au wrote: I'd argue that the GIS community has already decided that layers are the solution. QGIS, open source gis software, already handles layers much like ESRI. JOSM even handles layers. IMHO osm is post-layers ;-) This is quite a fascinating statement. Is there any content on the web describing the concept of a post-layer GIS in more detail? Astute observers of the concept might have remarked that since GIS is about layers, it is therefore perfectly logical that post-layers OSM uses PostGIS. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
2013/11/11 Jean-Marc Liotier j...@liotier.org Astute observers of the concept might have remarked that since GIS is about layers, it is therefore perfectly logical that post-layers OSM uses PostGIS. it doesn't, it uses postgres. Postgis is used for example for rendering the mapnik map. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On 11/11/2013 03:39 PM, Martin Koppenhoefer wrote: 2013/11/11 Jean-Marc Liotier j...@liotier.org mailto:j...@liotier.org Astute observers of the concept might have remarked that since GIS is about layers, it is therefore perfectly logical that post-layers OSM uses PostGIS. it doesn't, it uses postgres. Postgis is used for example for rendering the mapnik map. Well - there goes the consistency of the post-layers concept... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
2013/11/11 Jean-Marc Liotier j...@liotier.org Astute observers of the concept might have remarked that since GIS is about layers, A GIS is likely organized in layers, but it is not necessary. If you have one big database with everything in it (like OSM) you do not necessarily have to organize your data in layers (might also depend how you define a layer, e.g. layers for users, changes and changesets, geodata?). Of course you can restructure osm data into classical GIS layers (by interpreting them and making decisions, i.e. there is not the one possible layer system but infinite ones), but for what benefit? IMHO it would make our lifes more complicated rather than easier... cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On 11/11/2013 03:48 PM, Martin Koppenhoefer wrote: 2013/11/11 Jean-Marc Liotier j...@liotier.org mailto:j...@liotier.org Astute observers of the concept might have remarked that since GIS is about layers, A GIS is likely organized in layers, but it is not necessary. If you have one big database with everything in it (like OSM) you do not necessarily have to organize your data in layers (might also depend how you define a layer, e.g. layers for users, changes and changesets, geodata?). Of course you can restructure osm data into classical GIS layers (by interpreting them and making decisions, i.e. there is not the one possible layer system but infinite ones), but for what benefit? IMHO it would make our lifes more complicated rather than easier... C'mon, I was just attempting a feeble attempt at humor - I should have added a smiley ! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
If we agree that borders are a problem, then what is the best solution? Do you mean borders are a problem in general, or are there specific problems related to specific borders like those mentioned in this thread? I'd argue that the GIS community has already decided that layers are the solution. QGIS, open source gis software, already handles layers much like ESRI. JOSM even handles layers. IMHO osm is post-layers ;-) This is quite a fascinating statement. Is there any content on the web describing the concept of a post-layer GIS in more detail? nick *** WARNING: This email (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this email without appropriate authority. If this email was not intended for you and was sent to you by mistake, please telephone or email me immediately, destroy any hardcopies of this email and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this email is not waived or destroyed by that mistake. It is your responsibility to ensure that this email does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this email do not necessarily reflect the opinions of the Department of Transport and Main Roads, or endorsed organisations utilising the same infrastructure. *** ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Am 05.11.2013 14:49, schrieb Jochen Topf: So we have bad data in OSM and you want to fix it by making it harder to correct. Somehow I don't follow your argument... :-) While I do agree that it would be nice to have some kind of layering feature that allows us to aggregate date from different databases, this is a huge undertaking. It is much more than just adding a different database and let users change the API URL in their editors. How would you handle the ID spaces for instance. And it is totally unclear how things that are supposed to be changed together (think borders following a river or road) are to be handled. I suggest we keep the one database and think about how to improve the editors where needed. The JOSM filtering feature for instance is great to keep things pseudo-separate. +1 and I would like to combine it: JOSMs filtering feature is a really great starting point but it could be extended by a layering filter view which - defines layers by filters where one at a time can be selected for editing - provides a preset system to allow people to select the border layer or the water layer or the highway/road/path infrastructure layer in an abstract way without having to fiddle around with tag-specific filtering syntax on his own. Nevertheless there should be some warning structure wether someone changes a highway while moving a node of the boundary layer which is connected to both (highway and boundary), so it's not that simple to do, but it's possible and would be a great extension for the future - in JOSM as well as in other editors. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
2013/11/6 Peter Wendorff wendo...@uni-paderborn.de +1 and I would like to combine it: JOSMs filtering feature is a really great starting point but it could be extended by a layering filter view which - defines layers by filters where one at a time can be selected for editing - provides a preset system to allow people to select the border layer or the water layer or the highway/road/path infrastructure layer in an abstract way without having to fiddle around with tag-specific filtering syntax on his own. you specifiy which kind of objects you intend to modify (or select a preselection by topic someelse has provided) and the rest will be greyed out (or maybe invisible or only lines visible in grey but nodes not or with reduced size) and locked (not selectable, also not by select all, etc.), so you would be able to modify all specific stuff, also that which is glued to other stuff (and that other stuff would also be modified together if it is the same OSM object). This would IMHO be better than actual layers, because in my understanding with a real layer approach modifying something on one layer would not modify stuff on other layers (i.e. there would be node/way/rel copies in case the same geometry objects were used as well for other stuff than the selected). There might still be problems with geometry (eg. nodes) used multiple times for different ways or stuff part of relations (where the relation is not in the set that should be modified but would be implicitly modified anyway), were a user could potentially modify something he doesn't want to, now without even noticing because the effects on these other objects are hidden (could raise editor warnings for this kind of stuff maybe), but if you don't do it like this you will soon end up with lots of overlapping nodes and ways. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Hi Richard, On Tue, Nov 05, 2013 at 08:17:35AM -0500, Richard Welty wrote: there is an argument that some make that because borders are usually not easily verifiable on the ground, they don't belong in OSM at all. i'm somewhat sympathetic with the argument, but i also think that we have a bunch of data consumers that need/want borders. many map users, not so concerned with philosophical purity, expect to see at least some of these borders in a map. I oppose this idea. When the Data is broken - Fix it. When its to difficult to edit - Work on the editors (Multiple layers for JOSM so boundarys dont interact with other data). Moving the boundarys out of the OSM Dataset wont help anything. You only move the problem to somewhere else. And boundarys are very important for geocoding as its a necessary information whether an address belongs to city a or city b. Just as an anecdote RFC1925 - The Twelve Networking Truths [ ... ] (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection. [ ... ] Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
So we have bad data in OSM and you want to fix it by making it harder to correct. Somehow I don't follow your argument... :-) While I do agree that it would be nice to have some kind of layering feature that allows us to aggregate date from different databases, this is a huge undertaking. It is much more than just adding a different database and let users change the API URL in their editors. How would you handle the ID spaces for instance. And it is totally unclear how things that are supposed to be changed together (think borders following a river or road) are to be handled. I suggest we keep the one database and think about how to improve the editors where needed. The JOSM filtering feature for instance is great to keep things pseudo-separate. Jochen On Tue, Nov 05, 2013 at 08:17:35AM -0500, Richard Welty wrote: Date: Tue, 05 Nov 2013 08:17:35 -0500 From: Richard Welty rwe...@averillpark.net To: Talk Openstreetmap talk@openstreetmap.org Subject: [OSM-talk] Admin borders/separate database i brought up the subject of admin borders in the US over on talk-us and there was a lot of useful discussion. i think folks are mostly clear on the issues and tradeoffs, so i'd like to float a proposal for an evolved approach. i'm moving the discussion here because it's not just a US thing. basically, having admin borders mixed into the core OSM map is problematic for various reasons. in the US, we have a bunch of uncoordinated imports from different, inconsistent sources, and a bunch of hand editing that is sometimes well intentioned, and sometimes accidental, and not always correct. the resulting map can be quite ugly at times. there is an argument that some make that because borders are usually not easily verifiable on the ground, they don't belong in OSM at all. i'm somewhat sympathetic with the argument, but i also think that we have a bunch of data consumers that need/want borders. many map users, not so concerned with philosophical purity, expect to see at least some of these borders in a map. so the rough outlines of the proposal (feel free to kick this around) are as follows: a new database is created under the framework of OSM. the purpose of this DB is to contain borders. after it is reasonably complete and data consumers have been adapted to use it for their admin border needs, the old admin borders can be removed from OSM core. it uses the same schema and API so existing tools all work for editing. it has the same access restrictions as the current core OSM database; the only barrier to entry is that you have to learn enough about your editor to repoint it at this new DB. every member of the OSM community would retain the same access rights they have now. the minor barrier to entry, combined with the fact that it will be impossible to glue border nodes to other features, will probably address 98 or 99% of the issues we see today. for the US, we'd probably want to do a fresh build of borders, mostly from current TIGER although in some areas other sources might be more appropriate (for example, in Massachusetts MassGIS is available and probably a better choice.) one open question is do we move other borders into this map? there are lots of things like the New York State DEC borders for various bits of conserved land, National Park National Forest borders, and so forth that maybe out to move with admin borders. but perhaps we should start with admin borders only for proof of concept and to control the amount of work that needs to be done. richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
2013/11/5 Richard Welty rwe...@averillpark.net combined with the fact that it will be impossible to glue border nodes to other features, will probably address 98 or 99% of the issues we see today. The problem is, some admin borders are supposed to be glued to roads or rivers, and they change when the flow of a road or river changes. How do you deal with that? Other than that, I like the idea of separating different kinds of data. However, I wouldn't separate it that much. My idea was to prohibit gluing some types of tags to other types, and then using filters to hide some layers. But you can always justify gluing one type of tag to the other. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Hi Richard, In my opinion, changing the back end (which would be ton of work), is probably not the best way of addressing the issues you are seeing. We are still dealing with the hangover from the batch poorly done imports in 2009 and 2010. We also have an editor issue. A better approach would be to - Run an project to try to fix the imported poorly borders in the US, like we are fixing the tiger data. Or perhaps just pull them all out and re-import, state by state. - Make some changes to the editors to not allow dragging an entire admin border over, and not sticking other things to them by default. Thanks Jason On Tue, Nov 5, 2013 at 8:17 AM, Richard Welty rwe...@averillpark.net wrote: i brought up the subject of admin borders in the US over on talk-us and there was a lot of useful discussion. i think folks are mostly clear on the issues and tradeoffs, so i'd like to float a proposal for an evolved approach. i'm moving the discussion here because it's not just a US thing. basically, having admin borders mixed into the core OSM map is problematic for various reasons. in the US, we have a bunch of uncoordinated imports from different, inconsistent sources, and a bunch of hand editing that is sometimes well intentioned, and sometimes accidental, and not always correct. the resulting map can be quite ugly at times. there is an argument that some make that because borders are usually not easily verifiable on the ground, they don't belong in OSM at all. i'm somewhat sympathetic with the argument, but i also think that we have a bunch of data consumers that need/want borders. many map users, not so concerned with philosophical purity, expect to see at least some of these borders in a map. so the rough outlines of the proposal (feel free to kick this around) are as follows: a new database is created under the framework of OSM. the purpose of this DB is to contain borders. after it is reasonably complete and data consumers have been adapted to use it for their admin border needs, the old admin borders can be removed from OSM core. it uses the same schema and API so existing tools all work for editing. it has the same access restrictions as the current core OSM database; the only barrier to entry is that you have to learn enough about your editor to repoint it at this new DB. every member of the OSM community would retain the same access rights they have now. the minor barrier to entry, combined with the fact that it will be impossible to glue border nodes to other features, will probably address 98 or 99% of the issues we see today. for the US, we'd probably want to do a fresh build of borders, mostly from current TIGER although in some areas other sources might be more appropriate (for example, in Massachusetts MassGIS is available and probably a better choice.) one open question is do we move other borders into this map? there are lots of things like the New York State DEC borders for various bits of conserved land, National Park National Forest borders, and so forth that maybe out to move with admin borders. but perhaps we should start with admin borders only for proof of concept and to control the amount of work that needs to be done. richard ___ 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] Admin borders/separate database
On Tuesday 05 November 2013, Jochen Topf wrote: [...] And it is totally unclear how things that are supposed to be changed together (think borders following a river or road) are to be handled. And in principle the OSM data strctures are quite good for this, you can have a way with waterway=* that is part of a boundary relation. In reality borders are nearly always defined either through some real feature that is map-worthy in OSM on its own (most frequently rivers or watershed divides) or by straight lines/arcs between points with specified coordinates. The practical problem is that borders are mostly imported from external sources which do not contain the actual definition of the border but an approximation of varying accuracy. The only place where i have seen truely definition based borders in OSM are maritime boundaries like: http://www.openstreetmap.org/browse/way/48854191 -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Admin boundaries can also be seen, and surveyed, where the tarmac changes. Phil (trigpoint) -- Sent from my Nokia N9 On 05/11/2013 14:37 Christoph Hormann wrote: On Tuesday 05 November 2013, Jochen Topf wrote: [...] And it is totally unclear how things that are supposed to be changed together (think borders following a river or road) are to be handled. And in principle the OSM data strctures are quite good for this, you can have a way with waterway=* that is part of a boundary relation. In reality borders are nearly always defined either through some real feature that is map-worthy in OSM on its own (most frequently rivers or watershed divides) or by straight lines/arcs between points with specified coordinates. The practical problem is that borders are mostly imported from external sources which do not contain the actual definition of the border but an approximation of varying accuracy. The only place where i have seen truely definition based borders in OSM are maritime boundaries like: http://www.openstreetmap.org/browse/way/48854191 -- Christoph Hormann http://www.openstreetmap.org/browse/way/48854191 ___ talk mailing list talk@openstreetmap.org http://www.openstreetmap.org/browse/way/48854191 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
I'm agree with most of the others that removing the buondaries out isn't a good approach to solve current problems. I am agains layering in general, as this will only lead to more inconsistencies, in the end, most if not all stuff is somehow interlinked directly or indirectly. Even underground lines often follow roads or other feature on the ground. 2013/11/5 Pieren pier...@gmail.com Like in real world. In my country, when the road or the river is changing, the admin border may or may not change. And it can take time until the administration reacts. This depends on local/regional/national authorities who decide if the admin border has to be updated or not and when. So, if the river changes, move the river and keep the admin border at its current definition. This might require some unglueing nodes or ways. It surely augments complexity (inevitably) when boundaries are involved. Ideally there should be a distinction already in the OSM database between boundaries that ARE defined by a feature (like a river, coastline, peak, road, railway, ...) and those that only coincidently share the same position with them. If things were clean like this, you'd know how to operate when a feature changes that also is part of a boundary. In the current situation you also often don't know if perceived irregularities or offsets derive from official data or if the importer simply introduced errors in the conversion (or if the original data already was wrong). IMHO we should recommend to only reuse existing geometry for boundaries if it IS the boundary, not if it just happens to be at the right location. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić jan...@gmail.com wrote: The problem is, some admin borders are supposed to be glued to roads or rivers, and they change when the flow of a road or river changes. How do you deal with that? Well, historically, the border doesn't move. This has caused an on-going border dispute between California and Arizona (compounded by the fact that the Colorado River no longer regularly flows at all that far south), and some spits and islands only accessible from the neighboring state elsewhere in the country. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
So it seems like the get admin boundaries out of core OSM opinion has fairly decent support in the US but maybe not elsewhere. I think the reason for this is because we imported these borders a few years ago. Because the import process wasn't perfect, it created duplicate nodes wherever a border intersected a TIGER road even if there would normally be no reason for a node to exist on either one of the ways. These duplicate nodes then got merged together by a bot trying to clean up keepright duplicate node errors. But now because our boundaries are merged to roads where they have no business being merged, it makes them a nightmare to update. It also means that well meaning users see this and think that is the way it is supposed to be and make the problem worse. If the boundaries were in their own space we could update them at will from authoritative sources on a regular basis. Of course authoritative doesn't always mean accurate but for admin boundaries I think it is much more often the case than for most other physical things we can easily survey with a GPS device. Sure, you can sometimes find evidence of an admin boundary on the ground but this is definitely the exception rather than the rule around here. And even if you *can* it doesn't mean this is going to happen for each city in the US on a regular basis. So yes, I think we could have a better and more up to date map if we made boundaries separate from most other features in the database. The idea of some filters being active by default in editors has also been suggested before but some people are opposed to this because everyone can edit everything all the time in OSM. This is a nice sentiment but I personally have no problem saying that a first time mapper has no business touching admin boundaries that have the potential to break geocoding for an entire country/state. As a last note, Paul's example of the Colorado River is hardly unique. My county border is defined by the course of a river - when the border was defined. Since then a dam has been built which means most of the eastern side of the border now runs through a lake. The part of the river that is not in the lake changed course during a massive flood in the 1950s but the border still follows the original course of the river. Maybe the different handling of borders following a natural feature is another regional difference? Toby On Tue, Nov 5, 2013 at 9:18 AM, Paul Johnson ba...@ursamundi.org wrote: On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić jan...@gmail.com wrote: The problem is, some admin borders are supposed to be glued to roads or rivers, and they change when the flow of a road or river changes. How do you deal with that? Well, historically, the border doesn't move. This has caused an on-going border dispute between California and Arizona (compounded by the fact that the Colorado River no longer regularly flows at all that far south), and some spits and islands only accessible from the neighboring state elsewhere in the country. ___ 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] Admin borders/separate database
2013/11/5 Toby Murray toby.mur...@gmail.com I think the reason for this is because we imported these borders a few years ago. Because the import process wasn't perfect, it created duplicate nodes wherever a border intersected a TIGER road even if there would normally be no reason for a node to exist on either one of the ways. These duplicate nodes then got merged together by a bot trying to clean up keepright duplicate node errors. maybe you simply have had too many imports and bots and too few contributors in the US in the past ;-) A situation that seems to have changed a little bit in the last time, where it seems (looking from far) there is now an active OSM community that is growing... cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
* Paul Johnson ba...@ursamundi.org [2013-11-05 09:18 -0600]: On Tue, Nov 5, 2013 at 8:05 AM, Janko Mihelić jan...@gmail.com wrote: The problem is, some admin borders are supposed to be glued to roads or rivers, and they change when the flow of a road or river changes. How do you deal with that? Well, historically, the border doesn't move. It depends. In some cases, it doesn't move. In other cases, if the course of the river changes gradually by natural means (i.e. not someone digging a new channel for it), the boundary is considered to move with it. There's also the consideration that people might improve OSM's river or road data over time. If a boundary is glued to a road, but that road is poorly-aligned in OSM, the user who improves its accuracy should be updating both the road and the boundary. Personally, I think that OSM's ball-of-mud approach to data is one of its strengths and separating out its data into layers would be more of a negative than dealing with all of the issues that come from mingling administrative boundaries with everything else. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Two remarks: - I believe that the border matches geographic features is a bit of a red herring. There are all kinds of different practices over the world (here for example the borders are very very often drawn not to coincide with roads, and will run parallel to them at some distance to avoid fights over who is responsible for maintenance) and I don't think that using any single one of them is going to help the discussion. In the end generally geographic features tend to change slowly so ignoring such linkage is probably not a problem in reality. What is clear that a novice user does not expect that refining am unrelated feature will change of break an admin boundary. - I do not see how filters in editors do anything more to this issue than make it worse, particularly in the case when the border has been merged with an other object. Do you make the object immutable? Or do you simply hide the fact that you are now potentially breaking something (as JOSM does)? Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tuesday 05 November 2013, Toby Murray wrote: [...] The part of the river that is not in the lake changed course during a massive flood in the 1950s but the border still follows the original course of the river. Maybe the different handling of borders following a natural feature is another regional difference? That could well be. Many river borders are defined in laws/treaties as the actual river meaning they move when the river changes its course. There are still different variants of definition like center line of the river on either side as well as special contructs like a Condominium for the river itself as in parts of the Luxembourg/Germany border. It is also important to keep in mind that in case of borders authoritively defined through discrete points an officially released data set does not necessarily represent exactly this definition. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
2013/11/5 Simon Poole si...@poole.ch Two remarks: - I do not see how filters in editors do anything more to this issue than make it worse, particularly in the case when the border has been merged with an other object. Do you make the object immutable? Or do you simply hide the fact that you are now potentially breaking something (as JOSM does)? A filter can help only with a second feature, and that is prohibition of merging certain groups of tags. For example, prohibit connecting boundary=administrative with anything that is not also boundary=administrative. That is one way of creating layers within the same database. The next step is an entirely different database. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Am 05.11.2013 um 21:29 schrieb Christoph Hormann chris_horm...@gmx.de: It is also important to keep in mind that in case of borders authoritively defined through discrete points an officially released data set does not necessarily represent exactly this definition. And sometimes official or authoritive is not sufficient, there are a lot of disputed borders in the world, also between friends e.g. http://en.wikipedia.org/wiki/List_of_areas_disputed_by_Canada_and_the_United_States Or here: http://en.wikipedia.org/wiki/List_of_territorial_disputes Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tue, Nov 5, 2013 at 12:22 PM, Simon Poole si...@poole.ch wrote: - I do not see how filters in editors do anything more to this issue than make it worse, particularly in the case when the border has been merged with an other object. Do you make the object immutable? Or do you simply hide the fact that you are now potentially breaking something (as JOSM does)? Using filters in editors might solve the problem described in Richard's original post. Simply creating a filter is helpful, but ungluing the ways before full implementation of editor filters might be required. If we agree that borders are a problem, then what is the best solution? I'd argue that the GIS community has already decided that layers are the solution. QGIS, open source gis software, already handles layers much like ESRI. JOSM even handles layers. Modifying the editors to handle the complexity of deciding which nodes can be glued to others might be problematic. I'd like to hear from the dev community on which approach makes more sense. Martin - We in the US do need to expand our contributors. But we also have a wealth of data that could be imported. I'm of the camp that says imports can be a good thing. (I said can not are.) But as we clean up the TIGER import, it is clean that even now, much of the data in rural areas is poor. We need to grow our contributor base in those areas. -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Am 05.11.2013 um 22:56 schrieb Clifford Snow cliff...@snowandsnow.us: If we agree that borders are a problem, then what is the best solution? Do you mean borders are a problem in general, or are there specific problems related to specific borders like those mentioned in this thread? I'd argue that the GIS community has already decided that layers are the solution. QGIS, open source gis software, already handles layers much like ESRI. JOSM even handles layers. IMHO osm is post-layers ;-) Fortunately we got rid of layers in osm - not needed any more with free form tagging and a database backend capable to store the whole world. Layers also have a lot of disadvantages: of course it depends on the implementation, but probably you'd have to insert the same geometry multiple times and they are disjunct, so in case you have to modify something, you'll have to do it in all layers. One of the problems I could imagine with introducing layers in osm is that of stuff ending up in the wrong layer, or just in some layers and not in all necessary layers etc. There is really a lot that can go wrong, the information loss by loosing strong connections between features of different classes not even considered. Modifying the editors to handle the complexity of deciding which nodes can be glued to others might be problematic. I'd like to hear from the dev community on which approach makes more sense. To keep the freedom of the mappers and the flexibility that comes along, restricting what can be connected should be avoided, at max a warning could be issued. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
If someone thinks borders should be in a different database, they should just make the database. If that is the superior solution, data consumers will pick it up and start using that one over the existing one. I think having a few parallel databases would make a nice little ecosystem. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
On Tue, Nov 5, 2013 at 2:23 PM, Martin Koppenhöfer dieterdre...@gmail.comwrote: Do you mean borders are a problem in general, or are there specific problems related to specific borders like those mentioned in this thread? I was responding to the thread. Sorry for the confusion -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
