Pour info, sur la liste de discussion Mapnik :
https://groups.google.com/forum/?fromgroups#!topic/mapnik/vo1mhtokYfc
--
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus
___
dev-fr mailing list
dev-fr@openstreetmap.org
#4626: Potlatch2 toolbox disappears
--+
Reporter: SomeoneElse | Owner: potlatch-dev@…
Type: defect | Status: new
Priority: minor| Milestone:
Component: potlatch2|Version:
Resolution:
#4637: Problems dragging map and deselecting objects in P2
---+
Reporter: smsm1 | Owner: potlatch-dev@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: potlatch2 |Version:
Keywords:
#4637: Problems dragging map and deselecting objects in P2
+
Reporter: smsm1 | Owner: potlatch-dev@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: potlatch2 |Version:
Resolution:
Hi,
Here's another complex multipolygon that I'm not sure the Wiki properly
addresses: http://www.openstreetmap.org/browse/relation/11104
Situation: there are several holes within holes (
http://www.openstreetmap.org/browse/way/143604319 is one). The geometric
situation is clear (and wiki covers
On Wed, Oct 17, 2012 at 08:15:55AM +0200, Igor Brejc wrote:
Here's another complex multipolygon that I'm not sure the Wiki properly
addresses: http://www.openstreetmap.org/browse/relation/11104
Situation: there are several holes within holes (
Hi,
On 10/17/12 08:15, Igor Brejc wrote:
But the problem is in how to handle tagging in this case. The existing
wiki rules describe only the tagging of top outer rings, but they
don't mention how to handle various cases/combinations of tagging holes
within holes.
The area of the hole within
OK, a couple of things to consider:
- What happens if you modify your scenario so that the island is not a
forest, but a building instead?
- OSM multipolygon machine-processing requires that you determine the
actual roles of rings based on geometry, not on the membership roles. So in
On Wed, Oct 17, 2012 at 9:40 AM, Frederik Ramm frede...@remote.org wrote:
The area of the hole within the hole does not require special tagging,
as it is covered by the multipolygon itself. If you have a forest with a
hole in a hole, then that hole in a hole is forest as well.
True, but you
On Wed, Oct 17, 2012 at 09:56:23AM +0200, Igor Brejc wrote:
OK, a couple of things to consider:
- What happens if you modify your scenario so that the island is not a
forest, but a building instead?
Then you need a different MP relation for the inner part as Frederik has
described in
On Wed, Oct 17, 2012 at 10:02:35AM +0200, Igor Brejc wrote:
Yes, if you split it in two separate multipolygons, then it's clear. But
the problem is that Wiki does not explicitly forbids (just recommends not
to) doing it all in a single multipolygon, quote:
Such cascading is still recommended
On Wed, Oct 17, 2012 at 10:10 AM, Jochen Topf joc...@remote.org wrote:
On Wed, Oct 17, 2012 at 09:56:23AM +0200, Igor Brejc wrote:
OK, a couple of things to consider:
- What happens if you modify your scenario so that the island is not a
forest, but a building instead?
Then you
Am 17.10.2012 10:02, schrieb Igor Brejc:
On Wed, Oct 17, 2012 at 9:40 AM, Frederik Ramm frede...@remote.org
mailto:frede...@remote.org wrote:
The area of the hole within the hole does not require special
tagging, as it is covered by the multipolygon itself. If you have
a forest
2012/10/17 Igor Brejc igor.br...@gmail.com:
Yes, if you split it in two separate multipolygons, then it's clear. But the
problem is that Wiki does not explicitly forbids (just recommends not to)
doing it all in a single multipolygon, quote:
Such cascading is still recommended when the island
Currently if you try to look at the history of a bigger way or
relation (and/or one with many versions) it is most probable that you
run into a timeout. A solution to this would be to not get all the
versions of the object with all components in one rush when you first
click on way history (or
Currently if you try to look at the history of a bigger way or
relation (and/or one with many versions) it is most probable that you
run into a timeout. A solution to this would be
The solution to an API overload is always: use an appropriate third party tool.
In this case for example:
2012/10/17 Roland Olbricht roland.olbri...@gmx.de:
The solution to an API overload is always: use an appropriate third party
tool. In this case for example:
https://github.com/MaZderMind/osm-history-splitter
If you want to make a good service to the community then please make the
splitted
On Wed, Oct 17, 2012 at 11:19 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
Mixing tags from the outer ways and the relation to interpret what
kind of object the relation represents is odd. Things would be much
clearer if tags applying to the relation must go into the relation and
2012/10/17 Igor Brejc igor.br...@gmail.com:
Another thing that's odd is the duality of inner rings: they represent
holes, but they can also represent holes AND separate polygons at the same
time. Decision on which is which has to be made based on a vague notion of
difference in tagging.
This
On Wed, Oct 17, 2012 at 10:35 AM, Peter Wendorff
wendo...@uni-paderborn.dewrote:
And where's the problem?
The island is part of the area described by the multipolygon, as every
other outer way is, too.
It can be handled exactly the same as long as you don't want to do special
stuff
Hi,
On 10/17/12 12:58, Martin Koppenhoefer wrote:
2012/10/17 Igor Brejc igor.br...@gmail.com:
Another thing that's odd is the duality of inner rings: they represent
holes, but they can also represent holes AND separate polygons at the same
time. Decision on which is which has to be made based
On Wed, Oct 17, 2012 at 1:05 PM, Frederik Ramm frede...@remote.org wrote:
Igor probably refers to the situation where you have a multipolygon with
an outer and inner ring, and both rings are tagged landuse=forest. In that
particular tagging, which is supported by most applications as a form
Hi Igor.
But if we're talking about topology, why (as I understand it) are you
trying to force topological stuff in the multipolygon RELATION?
That solves, well... nearly nothing.
You have to do exactly the same work for any topological issues that are
not described by a mp relation, e.g.
Idea e.g. for OSMI or something like that:
Is that oddity (inner ways in multipolygons contain the tags of the
multipolygon) detected and reported as an issue in any QA tool yet?
Probably that would be a good idea for a new issue type/layer, so that
somewhen in future that could be considered
2012/10/17 Igor Brejc igor.br...@gmail.com:
On Wed, Oct 17, 2012 at 1:05 PM, Frederik Ramm frede...@remote.org wrote:
Igor probably refers to the situation where you have a multipolygon with
an outer and inner ring, and both rings are tagged landuse=forest. In that
particular tagging, which is
On Wed, Oct 17, 2012 at 1:37 PM, Peter Wendorff
wendo...@uni-paderborn.dewrote:
Hi Igor.
But if we're talking about topology, why (as I understand it) are you
trying to force topological stuff in the multipolygon RELATION?
That solves, well... nearly nothing.
You have to do exactly the same
On 10/17/2012 07:43 AM, Paweł Paprota wrote:
I agree. I will add changeset comments to changeset descriptions on the
demo instance and let's see how this turns out.
I said that but then I remembered that changeset metadata is not
available in the replication feed - only through public API or
On Wed, 2012-10-17 at 00:28 +0100, Tom Hughes wrote:
On 17/10/12 00:04, Alex Barth wrote:
- Are there technical reasons why changesets should tend to be
large? Are they expensive on some level?
I believe it's entirely because we've got so many people doing
mechanical or semi-mechanical
It's just your standard dump from
http://download.geofabrik.de/openstreetmap/europe/great_britain/
Now I know it's corruption (potentially on my part), I'm going to look
very carefully at how I used osmosis and how I wrote my app and see if I'm
doing anything daft.
Ok so I was swallowing
On 17 October 2012 13:53, Matt Amos zerebub...@gmail.com wrote:
getting to the point: this might to some extent mitigate the large
changesets issue, as it would allow bboxes to be collected at a smaller
granularity. however, it wouldn't be a full solution and we'd probably
still need
On 10/17/2012 03:30 PM, Andy Allan wrote:
Basically, I see no need to worry about the extent of bounding boxes,
and no need to move to having bboxes on uploads instead of changesets
or other complications. No matter what we do, if your interest in a
changeset extends beyond the details of its
On 17/10/12 17:20, Alex Barth wrote:
Matt Amos wrote:
from this, we get a single changeset/#id/upload
call which applies atomically.
Is that so? I thought changesets were not applied atomically leading to issues
where it is hard to find out what data got applied when a connection breaks
On 10/17/2012 06:20 PM, Alex Barth wrote:
It seems that OWL and Activity Streams have the exact same problem here...
I have been talking with Matt today on IRC and to me it looks like we
have been asking ourselves the same questions and overall I think that
replacing a big chunk of the
From: Alex Barth [mailto:a...@mapbox.com]
Subject: Re: [OSM-dev] Why are so many changeset so large?
BTW, I did some cursory digging in the changesets dump and found that
actually only a relatively small percentage of changesets are
geographically large. Trying to use the history tab they
On 17 October 2012 05:26, Roland Olbricht roland.olbri...@gmx.de wrote:
It has roughly the same importance than the main API
The OSMF Operations Working Group classify the planet.osm.org feeds at
the same (highest) level of importance to the project already. It's
absolutely core.
On the other
On 16 October 2012 11:02, Jochen Topf joc...@remote.org wrote:
I don't think we can bring all of this into a single export tab. In fact, if
we reduce all of this into a single export tab we risk alienating people who
try out whats offered, find it lacking and then go away not understanding
On 16 October 2012 00:17, Tom Hughes t...@compton.nu wrote:
On 15/10/12 23:40, Alex Barth wrote:
- Translations are a frequent bottleneck for copy changes, unclear how to
solve this.
I'm not sure why you think this, but I can only think it is because you are
overthinking the issue and
On 17/10/12 22:17, Andy Allan wrote:
On 16 October 2012 00:17, Tom Hughes t...@compton.nu wrote:
The way it works is this - you don't worry about translations as such at
all. You just make sure strings are translatable and we commit that and then
the translators get to work. Yes, when
On 17.10.2012 09:15, Jochen Topf wrote:
I think one reason people add bad changeset comments and organize their
changesets in a bad way is that for most people those changesets and the
comments just disappear into a black hole.
One thing that is also bad in my point of view ist that you can't
Tom Hughes-3 wrote
On 17/10/12 22:17, Andy Allan wrote:
On 16 October 2012 00:17, Tom Hughes lt;
tom@
gt; wrote:
The way it works is this - you don't worry about translations as such at
all. You just make sure strings are translatable and we commit that and
then
the translators get to
Le mardi 16 octobre 2012 14:29:08, Paweł Paprota a écrit :
I think this would be A LOT of work and probably not for only one person
but I for one would love to see end-users more involved during
development phase - testing, feedback, incremental improvements and all
that.
So the question
41 matches
Mail list logo
