Re: [OSM-talk] AAAA openstreetmap still doesn't use ipv6
Guys... what could it hurt to set up an ipv6.openstreetmap.org with only an -record or with and A -records pointing at the 6to4 -address associated with the current IPv4-addresse(s) to let users and admins experiment without causing any issues with the openstreetmap.org -name? It is automatically anycast-routed to the nearest 6to4 -server. Probably at the ISP, if not then at the nearest IX and it DOES work for the network-load of "real" servers every day. Marcus On Thu, Jul 2, 2009 at 12:39 AM, Steven Le Roux wrote: > > > On Wed, Jul 1, 2009 at 9:01 PM, Russ Nelson wrote: >> >> On Jul 1, 2009, at 2:47 PM, Thomas Schäfer wrote: >> > Maybe we should move the OSM-servers to the netherlands, because the >> > UK is not >> > able to serve the world. >> >> I appreciate your enthusiasm for IPv6, Thomas, but this topic is >> essentially completely unrelated to OpenStreetMap. When the time >> comes at UCL to move to IPv6, they will, and OSM will move with it. > > Just for your information, Free (French ISP) is ipv6 ready for 4 millions > subscribers in France. It's not because other ISP can't assume their > function or are technologicaly late that OSM should not have the lead > here > > And..; after all, isn't it the wealth of everey free/community/open project > to provide a solution even if there is only one person who need it ? > > So... the fact is... some guys can help with that, me, Thomas, how could we > manage in having a v6 stack/resolv ? > > Maybe this is the wrong place to debate on that but I don't know if there is > a more appropriate list... maybe talk-transit could be the noc list too ? > > >> >> Until then, this is all just wasted hot air. Maybe we could talk >> about mapping instead? >> >> -- >> Russ Nelson - http://community.cloudmade.com/blog - >> http://wiki.openstreetmap.org/wiki/User:RussNelson >> r...@cloudmade.com - Twitter: Russ_OSM - >> http://openstreetmap.org/user/RussNelson >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk > > > > -- > Steven Le Roux > Jabber-ID : ste...@jabber.fr > 0x39494CCB > 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osmosis Feature Request - Simplify Ways
On Fri, Jul 10, 2009 at 5:37 PM, wrote: > There are a few postings on how to simplify ways, which mostly point to > the JOSM plugin. I am wondering whether it would be possible for some Java > hacker to port this plugin into Osmosis. > > Reasoning: > The JOSM plugin is great for 1 or 2 ways, but is cumbersome to run against > large data set. > > As an Osmosis operation, this would enable users to reduce local data set > (not to be uploaded!) to save size/rendering time for GPS and paper maps. Traveling Salesman/LibOSM contains an osmosis-plugin to add certain map-formats and it already contains a WayHelper.simplifyWay -operation. Someone could write the required glue-logic to expose this operation as a task for osmosis. (I'm very, very busy at the moment but I can give the right pointers and answer questions.) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] access=destination valid only in one direction
On Fri, Jul 10, 2009 at 5:03 PM, Tobias Knerr wrote: > Stanislav Brabec wrote: >> Is there a way how to map a street with access=destination valid just >> only for one direction? In the reverse direction it is a standard drive >> through street. > > Using my proposal > http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags > it would be > > access[forward] = destination > > (or access:forward = destination, depending on what syntax people like > better) > > Of course that's way direction dependent. and it does not work NOW. Once it MAY be accepted in this OR a modified form (sometime in the future), then used in a significant number of places (much, much later), then the first programs may get a feature-request to implement support for it (where the normal access=destinationis already a bit tricky and not all programs have internal datastructures that allow such a construct at all) and quite a while later some developer may find the time to actually implement and test it. Then people will start filing bugs as it does not work perfectly the first time and later these bugs may be fixed. THEN it will be supported in SOME programs while others will still ignore it completely. Whereas drawing 2 ways works now. These 2 ways may even share exactly the same nodes and if they share the same nodes even turning around at any of these nodes will work. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Karlsruhe schema with address ranges
On Mon, Jul 20, 2009 at 10:19 AM, Joe Richards wrote: > > I am tagging some buildings which contain multiple addresses in them, but not > interpolated > http://www.openstreetmap.org/?lat=51.49994&lon=-2.61296&zoom=16&layers=B000FTF > > Since the listing of these numbers is long and sloppy, is it possible to use > the sub-proposal for ranges (e.g. 37-45) given here: > http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/House_numbers/Karlsruhe_Schema#Sub-proposal:_ranges_of_numbers_for_individual_nodes It is possible but not yet supported by any application. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
On Mon, Jul 27, 2009 at 5:19 PM, sergio sevillano wrote: > Martin Koppenhoefer escribió: > there is no need to break anything > height and maxheight can also be just nodes. > i think the wiki definition is quite clear for all. > > so for me: > - maxheight on the bridge stands for height limit of vehicles crossing > the bridge. [tag the bridge or a node] If you tag a node then it applies as a restrictions for ALL pathes that contain that node. Not only one way but not another that both share that node. > - height on the bridge stands for distance from the ground to top of the > bridge (construction). [tag the bridge] > - maxheight on the way under the bridge stands for height limit of > vehicles crossing under the bridge. [tag a way node] > > you can have all three at the same time. > > - height on the way under the bridge makes no sense, unless you want to > tag the asphalt or pavement height.(!) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Business listings
2009/7/27 Iván Sánchez Ortega : > El Lunes, 27 de Julio de 2009, John Smith escribió: >> At this point in time OSM needs businesses to embrace it more than it can >> offer back to businesses, so charging them would be like a slap in the >> face. > > You're doing it wrong. > > I do think that OSM should tap into government sources. Every country must > have some kind of business registry that could be cross-referenced with house > numbers. a) Store-Address(es) != Office-Address. b) The european database directive grants copy-rights to such collections of addresses preventing us to copy it in full or in major parts. c) Ther MUST be only one registry the one for taxes and that`s not public. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] address interpolation
On Sun, Sep 27, 2009 at 7:33 PM, David Earl wrote: > I'm experimenting with adding house numbering for the first time (and > using the address interpolation plugin). > > One common case I came across was 25, 25A, 25B, ... > > I wonder whether addr:interpolation=alphabetic could include this case 25A-25C should work with addr:interpolation=alphabetic . However not all software that supports interpolation at all, supports this interpolation-mode yet. 25-25A would not. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Updates its Data
On Wed, Oct 7, 2009 at 7:24 PM, Ian Dees wrote: > If I could figure out a way to report it, I would tell them that there might > not be a state park running through the middle of Minneapolis: > > http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=&sll=44.983256,-93.250151&sspn=0.040675,0.064373&ie=UTF8&hq=&hnear=&ll=44.983256,-93.250151&spn=0.040675,0.064373&z=14 "Boom Island Park" http://www.minneapolisparks.org/default.asp?PageID=4&parkid=264 seems to exist. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addressing Question
On Thu, Nov 12, 2009 at 2:13 AM, Ian Dees wrote: > Hi everyone, > > I'm looking at some donated street centerline data that has addressing data > in the form of "Right/Left From Addr" and "Right/Left To Addr" on each > street centerline. Can you identify the location of the Addr for the "From/To"? If so it would be easy to calculate interpolation-ways right and left of the streets using the Karlsruhe Schema. > Is there an accepted way of applying these tags to the > road ways? No, only in applying it to houses next to the street and special ways connecting next to the street for interpolating whole streets of house-numbers at once. > It doesn't really make very much sense to create and store a > separate way just for the addressing information. I disagree here because of the hundrets of special cases that absolutely must be handled to be correct that come from the fact that houses are not usually build in the middle of a road. > ...but I might have arrived too late in the argument to say that :-)... Yes, you are. ;) PS: I`m not reading the talk-US but as you crossposted there, so do I. Please let me know of yet another addressing-schema comes that is in actual usage to make sure my address-search does work on all the planet. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, Nov 14, 2009 at 8:56 AM, Dan Homerick wrote: > I'm not sure what you mean by, "That's just not happening." Clarify? > I should add that my comment about being highly in favor of the import is > riding on the assumption that we'll have something like 'tiger:reviewed = > no' (with editor support) to mark unreviewed areas. Ideally, an indication > that an address is unreviewed would be passed along by any services that use So, who did volunteer to write that editor-support? What editor is it? In case of josm, do you have the ticket-number for this enhancement/plugin? Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Server problem
On Mon, Dec 28, 2009 at 12:25 PM, Richard Fairhurst wrote: > Hi all, > > If you get a message from Potlatch complaining about "uninitialized > constant ActiveSupport::Multibyte", and asking you to e-mail me, you > don't need to. > > Something has changed on the server and Potlatch is simply passing the > message back to the user. Nothing has changed in Potlatch recently. > > I am on holiday so can't really look any further. However I can see > that my inbox is rapidly filling up... :| I got the same yesterday. When I tried again it was gone. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] donating read-only api-mirrors
On Fri, Feb 6, 2009 at 4:35 PM, Tom Hughes wrote: > Erik Johansson wrote: > >> How much of the DB load comes from the read only part of the API, and >> what if you remove the area limit on the map call? > > If I remove the area limit then somebody will do a massive query that > will suck up all the memory on the machine and everything will die. > > That limit is not (primarily) about the cost of gathering the required > data, though obviously that might become an issue as well, it's about > the fact that we are holding the whole result set in memory (several > times over in fact) on the rails server and those servers only have a > finite amount of memory. I'm not sure I understand why you do this. The most expensive call would probably be /map with a bounding-box. You query all the node, stream them out and keep the nodeIDs (but not the whole resultset with lat, lon, version, ...) in memory. Query the ways that use these nodes, keeping their IDs in memory. Then Query the relations, stream them out and forget about the nodes and ways while doing that. The most efficient data-structure to hold IDs in is either an array, bitset or a hashset, depending on your access-pattern. As the runtime should be dominated by the database-calls anyway and array or bitset can be used as it consumes less memory here. So...why is it that you hold the result-set of the nodes-query in memory again? Anyway, the question was on how much of the current load is done by non-writing queries (not just /map). Do we have an answer for that? Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] enclosed areas => borders
On Sat, Feb 7, 2009 at 4:17 AM, Franc Carter wrote: > > Hi, > > I am working on how to import the Australian suburb boundaries. I have > these as a set of shapefiles that define an enclosed area for each suburb. > > The suburbs share many points in common and the outline of one > areas overlays the outline of the neighbouring suburb(s) as would > be expected. > > It's fairly easy to de-dupe the points that make up the shape, but I'm > struggling with the next part I want to do. I'd like to split the areas in > to > sets of borders between the two adjoining suburbs. While I believe I have > an approach, it's looking annoying and complicated. > > So, does anyone know if there is a 'standard' algorithm for doing this ? How many nodes do 2 typical suburbs share? Many programs (like the adress search in my navigator) cannot yet use borders split up into multiple polylines grouped in an ordered relation. Considering that relations are not ordered until api 0.6 is public. (This is what is done for country-borders.) If it's not too many points on the shared polylines I see no problem with sharing just the nodes and having closed polygons for the suburbs as more programs will be able to make use of them. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Traveling Salesman - version 0.9.5 released
Sorry. For all those who got a ClassNotFoundError due to "org.java.plugin.PluginClassLoader", I just uploaded a bugfixed version. I forgot to include the new jpf.jar in the distributed executable jar. My mistake. Marcus On Wed, Mar 4, 2009 at 9:45 AM, wrote: > > Version 0.9.5 of the Traveling Salesman navigation-system for > OpenStreetMap has just been released. > > * With an improved plugin-system we now have an optional speechPack to add > voice-output. > (Note that higher quality voices and phonems for other languages can be > installed later.) > * Thanks to your help in the OSM-Wiki > (http://wiki.openstreetmap.org/wiki/Sample_driving_instructions) > we now not only have much improved driving-directions but also the first > translated driving-instructions. > * There are some major speed-improvements in the reference-implementation > of the OsmBin > file-format and the LODDataSet (automatic Generation of simplified low > zoom-levels). > * You can now file feature-requests, bug-reports and complains via the > help-menu. > * Testing without a GPS-device has become much easier with the new gpx-file > -controlpanel > reachable from the debug-menu. (fast forward and slow down in gpx-files) > > As we want to REACH VERSION 1.0 BY THE 23.3.2009 with the introduction of > the > OpenStreetMap API 0.6 we need YOUR HELP. We NEED BUG-REPORTS, feedback, > ideas > but also patches, plugins and feature-request. > Tell us what needs improvement! > Tell us what we did wrong! > Tell us what needs better documentation! > > http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=3&t=29 > http://sourceforge.net/project/showfiles.php?group_id=203597 > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple addresses/use for one building
On 3/13/09, paul youlten wrote: > Sarah, > > you could use (or adapt) the Karlsruhe Schema: > http://wiki.openstreetmap.org/wiki/Karlsruhe_Schema > > As I understand it you make a node _next_ to the way that is the > street to show which side of the street it is and tag it with: > > addr:housenumber = "1939" > > or if there are multiple apartments at one "node" or doorway: > > addr:housenumber = "220a, 222a, 224b, 226b" > > or > > addr:housenumber = "1 to 550" I'm not sure where you reat the third option. Can you point it out? Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple addresses/use for one building
On 3/14/09, paul youlten wrote: > As I understand the Karlsruhe schema you are allowed to tag > addr:housenumbers with non-numeric characters (e.g: "120b") so there > is no reason you couldn't tag a node "1 to 500" or "1–500". > > I suppose you could use addr:housename = "1 to 500" but that seems a > bit counter-intuitive. You could but unless anyone writing applications that search for house-numbers know about it your tagging will not be put to use. I`m preparing the proof of concept I wrote in the Karlsruhe meeting to make TS navigate to house numbers just this weekend. It`d not be able to find where house-number 246 was in your example until you pointed out this new semantics in your posting. As fas as I see it`s not yet documented. Is this schema in actual use? Non-numeric characters are for house-numbers that actually contain these characters. Like your "120b"- example. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple addresses/use for one building
On 3/14/09, paul youlten wrote: > MW: " ...your tagging will not be put to use" > > ... except by people looking at maps on screen or on paper - who might > find it useful. > > So, as usual, the people writing applications will have to do a little > dance with the people tagging nodes with house numbers. > > :-) I`ll implement the most important part of what is documented. Not even all of that. I`ll not even think of implementing schemas here that are not even documented for the simple case is already complex enough. Other values for addr:housenumber will simply regarded as illegal values and not found. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple addresses/use for one building
On 3/14/09, paul youlten wrote: > I would have thought that "1 to 500" would be easier to parse into > machine readable digits than "120b" > > or does "120b" == "120.2"? House-numbers are not at all times numbers. 120b is the string "120b". Parsing into numbers is only required for the documented interpolation of long streets and that only allowes some cases that can be implemented in a sensible number of man-hours. It does not make sense to try to parse that into real numbers as you suggested. There are cases out there strange enough for this to bot work in a generic way. Also it would not be possible to generate the original "housenumber" from such a number. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Traveling Salesman v0.9.8 released
Today I am proud to announce Traveling Salesman v0.9.8 . In a few weeks, when API 0.6 goes online we want to push v1.0.0 and to do that, we need your help! We need people who try it out, make bug-reports, suggest improvements, complain... we need YOU. Just click on the webstart-link below, try to use it and then go back to the forum linked below and tell us what you think. We want to make this as stable and reliable as possible to make a usefull navigator for you to use. Traveling Salesman - 0.9.8 == Download it: https://sourceforge.net/project/platformdownload.php?group_id=203597 Start it via Java Webstart: http://travelingsales.sourceforge.net/ts.jnlp Changelog: http://travelingsales.sourceforge.net/bugs/changelog_page.php Announcement: http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=3&t=49 After introducing house-numbers with v0.9.7, a great deal of new improvements are now getting published with v0.9.8. The most important are probably: * support for turn-restrictions and metrics for making turns with a completely new routing-engine -plugin TurnRestrictedMultiTargetDijkstraRouter. * support for determining what country a road is in and if it is inside a city * that is used to provide support for country-spefic traffic regulations like different maximum speeds and driving on the left side * we show the ETA and remaining kilometers in the routeInstructionPanel * Plugins now support having settings of their own and the Settings-dialog was cleaned up big time * We support many more speech-synthesesis -plugins with SpeechD and invoking external programs. * The low zoom-maps are now much faster and show more roads then before by applying improved road-combining-algorithms = Changes - 052: [Renderers] ODRPaintVisitor: simplified view missing significant parts of roads (Marcuswolschon) - erledigt. - 055: [Renderers] ODRPaintVisitor: map is really sluggish with a database full of detail (Marcuswolschon) - erledigt. - 076: [Route-Finding] Route is recalculated too often (Marcuswolschon) - geschlossen. - 075: [Driving Directions] NullPointerException in SimpleRouteDescriber if there is no myNextStep (Marcuswolschon) - geschlossen. - 072: [Databases] tags-keys changing (Marcuswolschon) - geschlossen. - 060: [User-Interface] Selectable predefined zoom for destinations or route (Marcuswolschon) - geschlossen. - 071: [User-Interface] Icon for roundabouts missing (Marcuswolschon) - geschlossen. - 074: [Route-Finding] TurnRestrictedMultiTargetDijkstraRouter (Marcuswolschon) - geschlossen. - 073: [Address-Search] AdressDB strips cyrillic characters (Marcuswolschon) - geschlossen. - 070: [User-Interface] show ETA and remaining distance to destination in UI (Marcuswolschon) - geschlossen. - 043: [User-Interface] add context menu to map with two items (combbs) - geschlossen. - 069: [Driving Directions] allow an external program to be used for voice-output (Marcuswolschon) - geschlossen. - 068: [Settings and Plugin-Management] support Config-Settings with a list to choose from (Marcuswolschon) - geschlossen. - 067: [Driving Directions] support voice-output using Speechd (Marcuswolschon) - geschlossen. - 066: [Settings and Plugin-Management] Settings cannot handle null values (Marcuswolschon) - geschlossen. - 065: [Settings and Plugin-Management] Improve plugin-system to let plugins have settings of their own (Marcuswolschon) - geschlossen. - 054: [Renderers] ODRPaintVisitor: highway=path without additional tags falsely rendered like a normal road (combbs) - geschlossen. - 059: [Driving Directions] 0.9.8-beta: still wrong instructions (Marcuswolschon) - geschlossen. - 061: [User-Interface] improved finnish translatrion (Marcuswolschon) - geschlossen. - 058: [User-Interface] search field has "steetname" (Marcuswolschon) - geschlossen. - 056: [Driving Directions] A "turn right" is needed but screen shows "follow road" (Marcuswolschon) - geschlossen. - 057: [User-Interface] add instructions to log-panel (Marcuswolschon) - geschlossen. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
I analysed the http://wiki.openstreetmap.org/index.php?title=Template:ValueDescription&action=edit and found that adding a "status=Approved|" to the parameter-list does what you want. Marcus On Sun, Mar 29, 2009 at 4:17 PM, Sam Vekemans wrote: > Hi, > From the wiki description, it seems that all tags .. keys/values > should have the basic template. > The last part of the template box is "status" and just shows up as > 'undefined' .. > How do i change that status, so it could be more meaningful? > > http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks > > Thanks, > Sam > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
On Sun, Mar 29, 2009 at 1:50 PM, Tobias Knerr wrote: > I've been implementing turn restriction support for some (still > unpublished) software recently -- and, of course, have also added every > restriction I could find to OSM. While the concept of "restriction" > relations generally works well, there is one thing in particular I'm not > really happy with: the effort that is required to handle via members. One question, does anyone have an implementation of turn-restrictions that have "via" as more then an optional specifier for a list of nodes to limit the effect of the restriction to only intersections where "from" and "to" meet at one of the "via"-nodes? (either "via" being a start- , end- or middle- node of "to" and "from")? We may have specified something that is just too complex to be implemented and debugged in every or the routers we have. PS: I found the idea of Nic to be easy to implement when he mentioned it before. It took me less then 2 days to convert a well documented and structured Dijkstra -implementation to work as he described and observed no visible performance loss so far. (You may try for yourself by using Traveling Salesman and calculating the same route while having either "MultiTargedDijkstraRouter" or "TurnRestrictedMultiTargedDijkstraRouter" in the options-dialog. No restart is required after changing the option.) Marcus http://travelingsales.sourceforge.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
I do not quite understand the structure. Yet I would like to know more about how it works. Is this a semantic mediawiki -feature? I am curious as to how to add more information to such a table. (Using either a wiki-category or this table -structure to document what tags are supported by what of the major applications.) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] state of preparing the TMC-import
I have made quite some progress in preparing the import
of the German TMC Location-Codes that was allowed to us
by the BASt. Now I would like to present what we may get into
the map in a few month.
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany
We are talking about:
28.520 points
1.699 segments
2.889 roads
16.966 intersections
6.135 administrative areas
932 other areas
spanning all of the german road-network.
Some of these roads, areas and points may not yet exist
in OSM.
There are no tools to do this import yet.
There will need to be due to the excessive topology-checing
required and that this import of Germany may just be the
first of some dozen other complete countries that use TMC
and thus the same exchange-format for their LocationCodeLists.
(No "today germany, tomorrow he world"-jokes please. Actually
Italy was the first to publish their LCL publicly without highly
restrictive licensing.)
There is one tool linked in the wiki that can convert the segments
and points (not yet ways, areas and intersections) into an osm-map
for visualisation and manual checking of yet to write import-tools.
== understanding TMC==
I managed to write a small TMC-parser and look at quite a
selection of messages. A proof of concept to use the tagging-
schema below in an actual working navigator with TMC-support
if slowly taking shape. (As the result of the import is to be computer
readable, I believe it should be proven that it can be read and
used in the intended way before starting to add elements the map
that may prove inadequate.)
I managed to get a good understanding of how locations
are referenced in the TMC-system and the given tagging-schema
with its location-codes, forward- and backward-references looks
adequate to the task. The challange may still be that the topology
of the very simplistic tmc-road-network has to be mapped to
our much more detailed osm-network and thus to a more refined
topology. (e.g. dual-carriageways and motorway-juctions are
just a simple line or point in tmc but a tmc-message mentioning
an affected direction may only affect one half of our dual-cardiageway.)
== tagging schema ===
I prepared a tagging-schema that I would very much like feedback on
as it does not yet look very "pretty". (Please use the Talk-Page)
Due to the fact that there are multiple countries with their own
Location-List and that some countries have more then one operator
and that a Tag can only have one value there was a decision to make.
For TMC:Roads the best way to tag them was relations as they are only
ordered lists of TMC:Segments.
But for TMC:Points=OSM:Nodes and TMC:Segments=OSM:Ways
there where 2 options:
1: use a relation with only one member and simple tags like
tmc:country
tmc:table
tmc:locationcode
or
2:tag the element itself but use more complex keys to allow
the same element to be referenced from multiple locationcodes.
I opted for the second as it is easier to understand, work with
and faster to obtain the referenced objects. (Points and Segments
are usually referenced by TMC-messages. Roads and Areas
more seldomly.)
I tried to avoid characters like "(" or "[" and stayed with ":" and "_"
instread, to avoid special-characters that need encoding.
Marcus
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hard Mapping / Roller coaster Log
2009/4/1 Kinya Inoue : > http://www.openstreetmap.org/user/ikiya/traces/346271 > > http://1.bp.blogspot.com/_9tw89LwNH4A/SdNnRbRmGxI/BAw/oPlF9yrKNE4/s1600-h/jc0904.jpg I still have GPS-logs of the rollercoasters in Europapakt (near Freiburg, Germany). However my old -159dBm gps-device was not fast enough with its fixes when leaving the part of the rollercoasters that where inside buildings. I'll make sure to ride again with the new one (-165dBm) when it is here. ;) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addr:streetnumber:first;last:left;right
On Mon, Apr 6, 2009 at 8:44 PM, andrzej zaborowski wrote: > Hi, > > 2009/4/6 Sam Vekemans : >> so for whats available in the dataset, along with the way listing the >> roadname;is_in and/or addr:city ... Is the listing of the first&last >> house number on the left side, as well as first/last on the right. it is "addr:city". There is no "left" or "right" as we use separate ways just for this. (There are reasond for it.) The perfect way are single houses drawn as polygons with building=yes and addr:housenumber=xy , the next best thing nodes places where each house is and the next best thing is 2 or more nodes where single house-numbers are known connected by a way tagged addr:interpolaton=even/odd/... to we can calculate where each house would be. You can use Traveling Salesman to test actual, working house-number search. >> For the geobase2osm script we excluded this feature, as we couldnt >> figure the best way to tag. >> Now I found that the data is also available in the canvec set. >> So one option is to have it as a way over top of the roadway. > > We're importing a small number of streets from a project called UMP > pcPL that has similar housenumber data as you describe (for *some* > streets). Here's how my script converts it to OSM: > > We add a addr:interpolation on each side of the way with an arbitrary > offset and with some simple heuristics to make it look correct > (although obviously it needs a manual check like all imported data - > to see that it corresponds with reality). I didn't add any address > relations but addr:street value can be used to add relations > automatically if needed. Here's a sample: > http://www.openstreetmap.org/?lat=52.23954&lon=21.10434&zoom=17&layers=B000FTF Sound cool! One suggestion: As this is automated anyway, try to add hints about what street the houses belong to. easy to implement version: Simply add a tag add:street=nam to the interpolation-ways slightly less easy to implement but easier to evaluate in address-search: add an associateStreet- relation I will download that area one of these days and play around with my address-seach a bit, okay? With so much test-data I may be able to improve the algorithm I use to associate the street with the house-numbers :) . Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addr:streetnumber:first;last:left;right
On Tue, Apr 7, 2009 at 6:22 PM, Florian Lohoff wrote: > On Tue, Apr 07, 2009 at 11:28:16AM -0400, Russ Nelson wrote: >> >> All the world is not Germany (echoing "All the world's not a VAX", >> but I date myself). Here in the USA, many areas were renumbered for >> the e911 initiative. The numbering? Well, it may vary from place to >> place, but for my area, it's the number of feet down your road divided >> by 25 (half the width of a buildable lot, so you can have a unique >> number on each side of the road). >> > > Is even or odd bound to a specific side of the road? You tag even/odd/... on the interpolation-way, not on the street. If you have to resort to interpolation you make a way between a first house and a last house and tag that way with how the interpolation is to be done and optionally what street this is for. >> Thus, for many roads near me, interpolation is not only usable, it's >> technically correct. Only if every house and intermediate street and garden around the house has the exact same exact size. And when someone else comes around to add the missing building-polygons with the shapes of every single house it gets obsolete anyway. Interpolation is just a usable way to tag many long streets with lots of houses in a sensible timeframe. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addr:streetnumber:first;last:left;right
andrzej zaborowski schrieb: > >> Or you can use the "type=associatedstreet"-relation. >> That one works without street-names and is just 2 relation >> with 1 tag and 2 members. Should be simple to code. > > Yes, I may do that, however... > Afterall this information doesn't seem all that useful - when you want > to be navigated to a given address (street+housenumer), you don't > necessarily want to go that street, you probably want to arrive at the > nearest point from that house, and very ofter that point is not the > "associatedStreet", sometimes that will be a driveway or an unnamed > living_street or a parking. The associatesStreets does not say anything about access. (There are other ways ment to explicitely give hints about access.) It says something about addresses. That this is house-number 12 of Street A and not house-number 12 of street B. (think of a house at a corner or between 2 streets or a named footway to some backyard crossing the interpolation-way.) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addr:streetnumber:first;last:left;right
On Tue, Apr 7, 2009 at 8:25 PM, andrzej zaborowski wrote:
>> createInterpolationWay(way w, int offset) {
>>
>> Node startInterpNode = new Node(w.getNode(0).location +
>> offset * w.getNode(0).getNextSegment().vectorNormalLeft());
>>
>> foreach (Node n in w.nodes except 0 and last) {
>> Vector last = w.getNode(0).getLastSegment().vectorNormalLeft();
>> Vector next = w.getNode(0).getNextSegment().vectorNormalLeft();
>> Vector normalVector =
>> new Vector((last[0] + next[0]) / 2,
>> (last[1] + next[1]) / 2).normalize()
>> Node interpNode = new Node(w.getNode(0).location +
>> offset * normalVector );
>
> If you just add the normal vectors it won't look very natural because
> the angle will determine the offset between the interpolation way and
> the road.
That is why I normalized the resulting vector, thus giving it
a length of 1. The offset will thus stay constant.
>> }
>>
>> Node endInterpNode = new Node(w.getNode(last).location +
>> offset * w.getNode(last).getLastSegment().vectorNormalLeft());
>>
>> }
>>
>> Not as difficult as andrzej thought it would be.
>
> This isn't the difficult part, ump2osm implements this too. The
> difficult part is the reverse mapping, if you wanted to convert OSM
> data back into a Garmin compatible format.
> (difficult but doable, ofcourse)
That is where associatedStreet and the trivial distance betwen a point
(node with addr:housenumber) and line (segment of the ways of the nearest
nodes) comes into play.
I implemented it. It was easy to do and is much more reliable then
I would have thought when we specified the Karlsruhe Schema
at the Geofabrik last year.
Marcus
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 501 Errors trying to use XApi?
I got that too. Sometimes it works, sometimes it does not. Marcus On 4/10/09, Jeffrey Ollie wrote: > I'm getting "501 Internal Server Error" trying to download an extract > (in my case the state of Iowa) using the XApi: > > http://www.informationfreeway.org/api/0.5/*[bbox=-96.723633,40.341797,-90.131836,43.549805] > > I've also tried going direct to the servers that > informationfreeway.org redirects you to but they all give 501s too. > > -- > Jeff Ollie > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Traveling Salesman - v1.0.0
Traveling Salesman - v1.0.0 == Traveling Salesman is a navigation application for use on nettops and laptops for the OpenStreetMap. It's focus is on clean, well documented code and modularity via plugins. Download it: https://sourceforge.net/project/platformdownload.php?group_id=203597 Start it via Java Webstart: http://travelingsales.sourceforge.net/ts-stable.jnlp Changelog: http://travelingsales.sourceforge.net/bugs/changelog_page.php V1.0.0 is the first stable version that is feature-complete and bug-free enough to be called 1.0. It is not "finished" as such a project never is. There are enhancements already present in the trunk-version that will become1.1 that are not yet part of 1.0 (TMC-support, more translations, new database-backends, ...). There are also still issues to be looked at. Importing maps is very slow but fully working. But you have to do the cut and call it 1.0 at some point and for us this cut was at 1.0.0-RC1. To try it out, you can use the 2 webstart-versions: http://travelingsales.sourceforge.net/ts-stable.jnlp and http://travelingsales.sourceforge.net/ts.jnlp a wizzard will guide you through the impor of your first map and configuration of the GPS-device. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Intriguing artifacts in GeoEye data
Sounds like buildings drawn precisely from high-res but poorly georeferences aerial photos. Looking at a sat-image you don´t know if not all of that photo is 50 or 200 meters off unless you are on the ground to compare. On Mon, Jan 18, 2010 at 4:51 PM, John F. Eldredge wrote: > If only man-made artifacts are displaced, but not the terrain, that must be a > mapping error. An actual earthquake land-shift would have displaced the > terrain, and moved buildings and other artifacts along with the land. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Maps on TomTom
On Wed, Apr 7, 2010 at 10:33 AM, John Smith wrote: > Most hardware hackers just require a new toy to start off, so perhaps > step one would be to get a donation of hardware and/or raise the funds > needed to purchase one. It´s the same TomTom-software they use on smartphones. No special hardware needed to develop for it. AND thes have an SDK. MArcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TMC comprehension questions.
On Fri, May 7, 2010 at 2:53 PM, colliar wrote: > 4 nodes for each location - means overall 8 nodes for these "doubled" points ? Points at intersectons in TMC exist once for each road because a point in TMC ever only belongs to one and only one road. So of cause they are doubled. That´s how the LCL works. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki key:maxspeed page
On Thu, Jul 15, 2010 at 7:17 AM, Alan Mintz wrote: > Looking at http://wiki.openstreetmap.org/wiki/Maxspeed , it clearly say > that, for countries that use imperial values (i.e. in miles/hour), we should > tag the speed limits shown on the signs (+ " mph"), not convert them to kph. yes. There where some very good arguments for it. > Assuming there is no significant disagreement with this, why should there be > a conversion table on the wiki page? Anyone mind if I remove it? not at all ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
