<br><div class="gmail_quote">2008/12/31 Stefan de Konink <span dir="ltr"><<a href="mailto:stefan@konink.de">stefan@konink.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">D Tucny wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not seeing it...<br>
</blockquote>
<br></div>
Let me first enlight you with the non-variated idea.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You seem to miss the point that to see the rest of the way:<br>
<br>
1) a request can be made with a new bbox like now is common practice<br>
if you want to edit a larger area<br>
<br>
<br>
But how do you know where the rest of the way is?<br>
</blockquote>
<br>
<br></div>
Ascii art:<br>
<br>
Your viewport/bbox;<br>
<br>
---------------<br>
| |<br>
| |<br>
| |<br>
| |<br>
| |<br>
---------------<br>
<br>
Nodes in the way;<br>
---------------<br>
| |<br>
| |<br>
| . . |<br>
| . . |<br>
| . |<br>
---------------<br>
<br>
Explicit order of them;<br>
<br>
---------------<br>
| |<br>
| 2 6 |<br>
| . 3 . |<br>
| . . 4 |<br>
| 1 . |<br>
---------------<br>
<br>
How the editor draws it:<br>
---------------<br>
| |<br>
| |<br>
| ., o |<br>
| o,' ',. |<br>
| ',o |<br>
---------------<br>
*see below for revisted thing*<br>
<br>
<br>
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;<br>
<br>
---------------<br>
| ---|----------<br>
| | | |<br>
| . | . | |<br>
| . . | | |<br>
| | | |<br>
-----------|--- |<br>
| |<br>
--------------<br>
<br>
The editor merges the result;<br>
<br>
---------------<br>
| |----------<br>
| |<br>
| . . . . |<br>
| . . |<br>
| . . |<br>
-----------| |<br>
|. |<br>
--------------<br>
<br>
<br>
And now it can connect; 1, 2, 3, 4, 5, 6, 7, 8, 9<br>
<br>
---------------,<br>
| +----------<br>
| |<br>
| ,., .-----.--. |<br>
| .' '.,. , |<br>
| '. . |<br>
-----------+, , |<br>
|., |<br>
--------------<div class="Ih2E3d"></div></blockquote><div><br>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..."<br><br>bbox:<br><br> ---------------<br>
| |<br>
| |<br>
| |<br>
| |<br>
| |<br>
---------------<br>
<br>Returned data:<br><br> ---------------<br>
| . |<br>
| . |<br>
| . . |<br>
| . |<br>
| . . |<br>
---------------<br>
<br>Order of nodes (multiple ways):<br><br> ---------------<br>
| 8 |<br>
| 4 |<br>
| 3 4 |<br>
| 4 |<br>
| 2 2 |<br>
---------------<br>
<br>How the editor draws them...<br><br> ---------------<br>
| o |<br>
| o |<br>
| o----o |<br>
| o |<br>
| o o |<br>
---------------<br>
<br>How I'd expect the editor to draw them, even with partial ways...<br><br>o<br>\ <br> \ o o<br> \| |<br> -|\-|----------<br> | | |. |<br>o--|-+--+\---.----|---o<br> o--+-+.--\------+----o<br>
o--|-+--+----.\---|---o<br> | . . \ |<br> -|---|--------- \<br> |
| o<br> | o<br> o<br> <br>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...<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) CLick on the way and do a full<br>
<br>
So replacing one request with multiple requests... erm... Assuming you could actually find the way...<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br>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)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
I don't see your buffer point. I would like to return the nodes that<br>
are exactly within the bbox. Like what is expected.<br>
<br></div>
<snip><br>
</blockquote>
<br>
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.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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...<br>
</blockquote>
<br></div>
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.<br>
<br>
I guess you would like to make it:<br>
<br>
---------------<br>
| |<br>
| |<br>
| ,., o|----o<br>
| o' '.,. |<br>
| '. |<br>
------------,--|<br>
o<br>
<br>
<br>
And indeed this seems a much better approach.<div class="Ih2E3d"></div></blockquote><div><br>This is what I was trying to illustrate without ascii art :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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... <br>
</blockquote>
<br></div>
I hope I can convince you with my ascii art ;)<div class="Ih2E3d"></div></blockquote><div class="Ih2E3d"><br>I hope mine can too ;)<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Either way, a maximum of 2000 nodes in a way would work in both scenarios... So no arguments from me...<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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...<div class="Ih2E3d">
</div></blockquote><div><br>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... <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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...<br>
</blockquote>
<br></div>
I have friends in many places ;) Thanks for your comments, they really changed my view on the matter :)<br><font color="#888888">
</font></blockquote><div><br>Cool :)<br><br>d <br></div></div><br>