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

[Roberto Navoni]

Happy New Year ;)
Best Regards
Roberto Navoni
> 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
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
> ------------------------------------------------------------------------
>
>
> Nessun virus nel messaggio in arrivo.
> Controllato da AVG - http://www.avg.com 
> Versione: 8.0.176 / Database dei virus: 270.10.1/1870 -  Data di rilascio: 31/12/2008 8.44
>
>