[OSM-dev] ROMA servers down - osmosis large way problem

[D Tucny]

2008/12/31 Stefan de Konink <stefan at konink.de>

> D Tucny wrote:
>
>> That would be quite nasty, seeing node 8, but not having a line connecting
>> it anywhere? For rendering, that would be pretty useless, for editing it
>> would be a pain in the bum, especially if there was a node 9 somewhere else
>> outside the bbox...
>>
>
> Notice variation. It is an editor thing, and can made useful.
>

I'm not seeing it...


>
>
>  To get the useful nodes 7 and 9, you'd either have to get the whole way as
>> a seperate request and then get the nodes, as seperate requests or make
>> guesses as to which direction and how far away those nodes are and do bbox
>> requests... You'd need at least a one node buffer around 'in box' nodes to
>> be of use for anything... i.e. if only node 10 is within the bbox, you'd
>> need to return 9 and 11 too, at least, even if they are outside the bbox...
>> in your example, that would return nodes 3, 6 and 7 too...
>>
>
> You seem to miss the point that to see the rest of the way:
>
> 1) a request can be made with a new bbox like now is common practice if you
> want to edit a larger area
>

But how do you know where the rest of the way is?


>
> 2) CLick on the way and do a full
>

So replacing one request with multiple requests... erm... Assuming you could
actually find the way...



>
> I don't see your buffer point. I would like to return the nodes that are
> exactly within the bbox. Like what is expected.
>

OK, as an example... I get a bbox that covers a 500m x 500m area... 10 ways
run through that area, including 2 I'm actually interested in... right now,
as long as those 10 ways have nodes within the bbox I get them all and I can
see how they interact and where they go after leaving my bbox giving a
useful hint as to where to expand my bbox should I want to edit a way that
leaves it... With your suggestion I could see that I could have say 1 line,
between 2 nodes and and 5 additional standalone nodes, the only thing I know
is that the two nodes joined are part of one way and the other 5 nodes are
either not part of that way, or, if they are, that there are other nodes,
somewhere outside of the bbox that connects them... if I select the one
visible way, as none of the nodes are highlighted, I'd know that they were
not part of that way, so, they must be either standalone nodes that are not
part of a way, which, with their lack of tags would suggest that they were
bad edits, or, they are indeed part of a way, but for which there are no
other nodes to be connected to... if we assume that they were further
highlighted in your suggestion to show that they were special way nodes as
opposed to non way nodes, I'd know they were part of a way, but, I don't
know which way or where infact additional nodes are... I can blindly extend
the bbox and cross my fingers hoping I'll get more nodes to be able to
visualise part of the way, or, I guess, the editor can be made to give me a
list of ways that are missing nodes so that I can download them in full
manually... My buffer suggestion was to allow ways with member nodes within
a bounding box to be represented simply... I still, to be honest, think the
whole idea is somewhat crazy and I personally would not like it... But...
without either a) the ability to retreive the next node in a way outside the
bbox, or b) the ability for an editor to automatically fetch this missing
information at the cost of a very significant cost in time... I don't see
this as being anywhere near a workable solution...

I can see that your suggestion for modifying ways could be potentially
useful to reflect changes to ways without having to retransmit the entire
way, but, I don't like idea of by default not getting all the relevant
information for an area...


>
>  To me, this feels like a significant overcomplication with no significant
>> benefits... Far easier would be to just limit the size of ways... Hmm, I'm
>> sure that's been mentioned already...
>>
>
> You want to limit the ways because then you would request only 2k of nodes
> cluelessly instead of what you actually see? That is an over simplification.
>

Still preferable in my eyes to be forced to be without a clue, not being
able to see what you actually see due to having relevant data effectively
hidden...

We obviously have different viewpoints on this... I'm happy with the way it
works now, you want it to work differently... If you want it to work in a
way that makes sense to you, then I don't have an issue you implementing
that as an option... but... I'd want to equally be able to choose a way that
makes sense to me, which I'd also expect to be the default...

Either way, a maximum of 2000 nodes in a way would work in both scenarios...
So no arguments from me...

I expect the 2000 node limit will be implemented prior to your solution
being ready as the 0.6 API is already pretty much there... So, that's
that... I will try to keep an open mind though, once your solution is ready,
I'll evaluate it on it's merits too, but, I suspect you'll also have to make
friends with some editor devs or take up editor modifying yourself to
attempt to avoid noticably reducing the current usability too much...

d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081231/aa3883d7/attachment.html>