On 16/08/07, <b class="gmail_sendername">David Earl</b> <<a href="mailto:david@frankieandshadow.com">david@frankieandshadow.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On 16/08/2007 17:16, Gabriel Ebner wrote: > Over the last few days I've developed working prototypes of the server code and > JOSM that do away with segments and make ways simple lists of nodes. I think this would speed quite a lot of things up and improve integrity.

But I'm worried we might have a lot to clean up manually. I think it would make a lot of sense to make this change at the same time as relationships/entities are introduced. Then we get only one hit on JOSM.

> Migration should cope with all sorts of ways in the current database, but it > does not convert historical ways.  Obviously it also deletes all segments and > their histories. Would we lose anything vital in tags on existing segments?

What do you do about the many ways which, though deprecated, have disjoint sequences of segments and/or unordered sequences of segments? Do you end up with two ways where there was one (good) or do you effectively end up with a connection between the disjoint pieces (bad)?

</blockquote><div> Well, assuming both extensions work and are Good: Maybe do entities first? It strikes me that most of the information currently on segments can be migrated to entities as you can model a segment with an entity.

<br><br> - discard any empty segments<br> - discard any segments which contain just tags that are also on a way they are part of<br> - way unwayed segments, moving any tags up<br> - make the remainder entities with entity_type=segment, and nodes with roles 'from' and 'to'

I'm not sure whether this would actually work on the data or not (the feasibility probably depends on how many segments are left at the end), but it means you don't loose any information, and doesn't require a deadline for people editing to save their data.

<br></div><br><br></div>