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

D Tucny d at tucny.com
Wed Dec 31 20:13:28 GMT 2008


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

> D Tucny wrote:
>
>> I'm not seeing it...
>>
>
> Let me first enlight you with the non-variated idea.
>
>     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?
>>
>
>
> Ascii art:
>
> Your viewport/bbox;
>
>  ---------------
> |               |
> |               |
> |               |
> |               |
> |               |
>  ---------------
>
> Nodes in the way;
>  ---------------
> |               |
> |               |
> |    .        . |
> | .      .      |
> |           .   |
>  ---------------
>
> Explicit order of them;
>
>  ---------------
> |               |
> |    2        6 |
> |    .   3    . |
> | .      .  4   |
> | 1         .   |
>  ---------------
>
> How the editor draws it:
>  ---------------
> |               |
> |               |
> |    .,       o |
> | o,'  ',.      |
> |         ',o   |
>  ---------------
> *see below for revisted thing*
>
>
> User thinks; mmm... that way is outside my bbox, lets request the area next
> to it. Now that area will also return a partial way;
>
>  ---------------
> |            ---|----------
> |           |   |          |
> |    .      | . |          |
> | .      .  |   |          |
> |           |   |          |
>  -----------|---           |
>            |              |
>             --------------
>
> The editor merges the result;
>
>  ---------------
> |               |----------
> |                          |
> |    .        .    .   .   |
> | .      .                 |
> |           .   .          |
>  -----------|              |
>            |.             |
>             --------------
>
>
> And now it can connect; 1, 2, 3, 4, 5, 6, 7, 8, 9
>
>  ---------------,
> |               +----------
> |                          |
> |   ,.,        .-----.--.  |
> | .'   '.,.     ,          |
> |          '.   .          |
>  -----------+, ,           |
>            |.,            |
>             --------------
>

Attempting to use ASCII art to illustrate my example... "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..."

bbox:

 ---------------
|               |
|               |
|               |
|               |
|               |
 ---------------

Returned data:

 ---------------
|     .         |
|          .    |
|  .      .     |
|          .    |
| .  .          |
 ---------------

Order of nodes (multiple ways):

 ---------------
|     8         |
|          4    |
|  3      4     |
|          4    |
| 2  2          |
 ---------------

How the editor draws them...

 ---------------
|     o         |
|          o    |
|  o----o     |
|          o    |
| o  o          |
 ---------------

How I'd expect the editor to draw them, even with partial ways...

o
\
  \  o  o
    \|  |
    -|\-|----------
   | |  |.          |
o--|-+--+\---.----|---o
 o--+-+.--\------+----o
o--|-+--+----.\---|---o
   | .  .         \ |
    -|---|--------- \
     |   |            o
     |   o
     o

Expanding bboxes gets some of the nodes, but, would need to be repeated in
each direction to get all of them, with no guarantees if the bbox was not
expanded far enough...


>
>
>
>     2) CLick on the way and do a full
>>
>>  So replacing one request with multiple requests... erm... Assuming you
>> could actually find the way...
>>
>
> If a part of your way is visible you should be able to request it by the
> usual 'rest' command. /ways/[id] or alternatively multible bboxes.
>

TBH, I was specifically thinking of the JOSM interface as it is now, whereby
if a node was effectively not joined, it would appear like any other
untagged node, which, as long as you had a middle mouse button you could
select the way, but, if not, it the current interface would make it somewhat
difficult to actually select the way, even if there was a 'get entire way'
option within josm... (I primarily use a two button mouse, I have a 3 button
(2 + mousewheel) mouse plugged in also purely for using the 'What's at this
point' function within JOSM which before adding the second mouse was
somewhat troublesome)


>
>     I don't see your buffer point. I would like to return the nodes that
>>    are exactly within the bbox. Like what is expected.
>>
>> <snip>
>>
>
> I do see some of your points. Those 'nodes' should be not marked as a node
> 'symbol' or 'colour' but as an endpoint. So there is explicit knowledge that
> this node when clicked on is viewed as a way. Otherwise it is confusing if
> you see all sort of artifacts ath the sides of the bbox (then it would be
> useful to have always at least two nodes on screen.
>
>  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...
>>
>
> What is exactly transfered is a thing that should be tweaked indeed, even
> for rendering you want something that is going outside of the bbox.
>
> I guess you would like to make it:
>
>  ---------------
> |               |
> |               |
> |   ,.,        o|----o
> | o'   '.,.     |
> |          '.   |
>  ------------,--|
>             o
>
>
> And indeed this seems a much better approach.
>

This is what I was trying to illustrate without ascii art :)


>
>
>  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...
>>
>
> I hope I can convince you with my ascii art ;)
>

I hope mine can too ;)

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

True but as Martijn already pointed out, there is just still stuff that
> should be 'one', coastallines. And if I may add, I would really like to
> apply algebra for geo stuff to that kind of things. That will not work if
> OSM limits 2k. And OSM-companies suddenly start to offer shapefiles where it
> actually is possible to do that kind of lookups with merged coastallines,
> that is a bit a turn off to me...
>

I'm sure it wouldn't be too complex with a few recursive lookups to get an
entire coastline, where you could, if you so wished merge them together and
perform any, not usual for typical use, function on them, including applying
algebra... I'm sure with your own copy of the planet, especially if loaded
into a database it would quick and simple to achieve this too... admittedly,
not as quick as if the database natively held the entire coastline as a
single way, but, trivial none the less... An example of such cleverness
would be the coastline checker stuff done by Martijn...


>
>
>  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...
>>
>
> I have friends in many places ;) Thanks for your comments, they really
> changed my view on the matter :)
>

Cool :)

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


More information about the dev mailing list