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

Stefan de Konink stefan at konink.de
Wed Dec 31 15:19:42 GMT 2008


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

  ---------------,
|               +----------
|                          |
|   ,.,        .-----.--.  |
| .'   '.,.     ,          |
|          '.   .          |
  -----------+, ,           |
             |.,            |
              --------------



>     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.

>     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.

> 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 ;)

> 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 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 :)


Stefan




More information about the dev mailing list