In response to the latest round of bugs, i wrote bug 13:Too many tags.<br><br>When writing the page, i found the solution is always in the clarity of the argument. When the argument is so clear, there's even less arguments. :-)<br>
<br>Look forward to any feedback.<br><br><a href="http://wiki.openstreetmap.org/wiki/Talk:Canvec2osm#Bug_13:_Too_Many_Tags">http://wiki.openstreetmap.org/wiki/Talk:Canvec2osm#Bug_13:_Too_Many_Tags</a><br><br>Cheers,<br>Sam Vekemans<br>
Across Canada Trails<br><br clear="all">Twitter: @Acrosscanada<br>Facebook: <a href="http://www.facebook.com/sam.vekemans">http://www.facebook.com/sam.vekemans</a><br>
<br><br><div class="gmail_quote">On Wed, Jun 17, 2009 at 2:59 PM, Sam Vekemans <span dir="ltr"><<a href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Good point.<br>
Each road SHOULD be a relation which is made up of street (address<br>
block numbered sections).<br>
Geobase already does this 1st part well.<br>
What if we start doing this:?<br>
<br>
Create a relation route, called 'theNameOfTheRoad' and have it<br>
attributed to each segment. And step 2 would be to remove just the<br>
'name=*' tag.<br>
The surface type and class designation would remain with each way segment.<br>
<br>
So... Why not train the renders to ... Automagically check for a relation?<br>
<br>
Or maybe just render intersecting roads with the same name, to behave<br>
like a solid road?<br>
<br>
This would make house numbering and using the roads easier.<br>
<div><div></div><div class="h5"><br>
On 6/17/09, Michael Barabanov <<a href="mailto:michael.barabanov@gmail.com">michael.barabanov@gmail.com</a>> wrote:<br>
> (Sorry for repeating myself) it's not only splitting; larger<br>
> streets and highways consist of a way for each direction in GeoBase.<br>
> This is also the recommended way to map those in OSM (see for example<br>
> <a href="http://josm.openstreetmap.de/wiki/Introduction" target="_blank">http://josm.openstreetmap.de/wiki/Introduction</a>, Conventions), but often<br>
> they are not, at least in the areas I've looked into.<br>
> This additional complication has to be taken into account while<br>
> automating the process.<br>
><br>
> Michael.<br>
><br>
> On Wed, Jun 17, 2009 at 04:31:06PM -0400, Richard Degelder<br>
> (<a href="mailto:rtdegelder@gmail.com">rtdegelder@gmail.com</a>) wrote:<br>
>> On Wed, Jun 17, 2009 at 2:02 PM, SteveC <<a href="mailto:steve@asklater.com">steve@asklater.com</a>> wrote:<br>
>><br>
>> ><br>
>> > On 12 Jun 2009, at 18:54, Richard Degelder wrote:<br>
>> ><br>
>> > William Lachance wrote:<br>
>> >><br>
>> >> Look at this from another angle: Should we split up all the existing<br>
>> >> OSM<br>
>> >> road data that people have put in to add in GeoBase UUID information?<br>
>> >> The simple answer is that at some point we are going to have to.<br>
>> >><br>
>> >> If we want to add the attributes available from GeoBase, and to be able<br>
>> >> to<br>
>> >> update it from future GeoBase updates, then we are going to have to<br>
>> >> find a<br>
>> >> way to add the GeoBase UUID information and,<br>
>> >><br>
>> ><br>
>> > Stupid question but my understanding is that TIGER claims to reuse UIDs<br>
>> > from release to release but doesn't really. So, what is the probability<br>
>> > with<br>
>> > GeoBase? Just saying it might be worth thinking about before doing all<br>
>> > the<br>
>> > work.<br>
>> ><br>
>><br>
>> I may not be the best person to answer the question, I can easily think of<br>
>> a<br>
>> few others that would be better qualified, but it is my understanding that<br>
>> the GeoBase UUIDs, the NIDs, are persistent and the primary means of<br>
>> identifying a segment or item. Currently we are importing the new data<br>
>> from<br>
>> GeoBase and leaving the current user input data alone but if we want to<br>
>> take<br>
>> advantage of the extra data that comes from GeoBase we are going to have<br>
>> to<br>
>> find a way to split the current ways to add the data, such as the GeoBase<br>
>> NIDs and street names, at some point.<br>
>><br>
>> I am hoping that we can do so in a manner that will not require users to<br>
>> manually do the splitting but that a script can be written to do most of<br>
>> the<br>
>> work for us. There are probably going to be points where we are going to<br>
>> have to look at the data and make corrections but they should, very<br>
>> hopefully, be infrequent. Once the ways are split we can use other tools,<br>
>> possibly RoadMatcher, to transfer data from GeoBase to OSM to fill out the<br>
>> map even more.<br>
>><br>
>> Steve Singer, the person who is doing most of the work with the import of<br>
>> the GeoBase data, pointed out recently that there were new updates for<br>
>> areas<br>
>> that he had already imported the data and so we have the oppertunity to<br>
>> really test the ability to update OSM from a GeoBase update.<br>
>><br>
>><br>
>><br>
>> > Best<br>
>> ><br>
>> > Steve<br>
>> ><br>
>> > Richard Degelder<br>
><br>
>> _______________________________________________<br>
>> Talk-ca mailing list<br>
>> <a href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a><br>
>> <a href="http://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ca</a><br>
><br>
><br>
> _______________________________________________<br>
> Talk-ca mailing list<br>
> <a href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ca</a><br>
><br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
Twitter: @Acrosscanada<br>
Facebook: <a href="http://www.facebook.com/sam.vekemans" target="_blank">http://www.facebook.com/sam.vekemans</a><br>
</div></div></blockquote></div><br>