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
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.
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
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
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
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
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
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
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.
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
...@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
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
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
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=*
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
