Re: [OSM-talk] New dimension of vandalism
On Thu, 27 Aug 2009 08:10:01 +0200, Renaud Martinet kar...@gmail.com wrote: On Wed, Aug 26, 2009 at 7:47 PM, Richard Fairhurstrich...@systemed.net wrote: Renaud Martinet wrote: I guess that the highway tag used to describe physical features of different types of roads back when OSM was quite UK-centric. Nope - UK highway tagging, which was of course the original, has always largely been aligned to administrative classifications. highway=motorway - UK motorway (Mx or Ax(M)) highway=trunk - UK primary A-road (Ax with green signs) highway=primary - UK non-primary A-road - yes, really (Ax with black/white signs) highway=secondary - UK B-road (Bx) We do have a super special, very rarely used exemption known as the Oxford High Street Exemption, though. cheers Richard Sure I used a shortcut here. :) But most of the values of the highway tag were corresponding to a type of road: motorway would be 2x2 with central seperator, trunk would be mostly the same but with the possibility of smaller roads directly leading onto the trunk (no sliproad), etc. I know that the trunk value is the one that forced us to consider the highway tag a bit differently than what was on the map features at the time, because we have nothing like that. And it's probably the same for other countries. So we used the highway tag to describe the importance in the road network. Renaud. I think the best way to solve this is for each country to define its needs. Norway have made very good definitions of their highways, while Brazil where I live now are still trying to define it. For Brazil we have 3 sources of funding (+ private, but that is usually on license for one of the 3), Federal, State and Municipal, and 6 physical differences, small unpaved, small paved, medium unpaved, medium paved, large unpaved, large unpaved. Trunc and Motorway is easy to spot as they are separated by distance, have multiple lanes, construction of intersections, usage of light signals etc. The other types of road is a little tougher to destinguish. Even small unpaved roads have free-flow intersections, so that cannot be used as an identifier. IMO physical, legal, and administrative (funding) classifications should be tagged, some of these can be surface, lanes, (the dredded) smoothness, ref (in Brazil this can identify all federal and stately roads), network, maxspeed (and eventually minspeed), traffic_signal, etc can all be used for this. I do not believe it is possible to get a global consensus on the use of the existing highway tag, and national definitions are necessary for getting cinsistant tagging schemas. Just my R$0,02. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Tue, 25 Aug 2009 10:47:14 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. When you are getting this complicated on it, maybe it is better to handle this in relations? This way each special condition can be handled separately without cluttering the map with tags. A road can have a set of general access tags, and than use relations for the complicated access conditions, such as psv only on school days, goods delivery 10-12 mon-fri + 11-12 saturdays in july, destination for taxies exept saturdays after 22, and so on. That will allow you to do all these special condition without access:vehicle:forward/backward. I havn't seen that complicated access restrictions in the areas I map, so I have no need for it, but I know that reality is a little different in Europe. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009 21:33:27 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) Not all tags in access need everey value, in many cases when specifying, yes/no/dedicated cover more than enough. Only the general access need this variety of values. BTW I know of cases which could be tagged access=private + agriculture=yes + forestry=yes. Even more appropriate is hgv=no + agriculture=yes, since many of these agricultural vehicles can have a max weight far above 3.5 tonnes, I have myself maneuvered almost 10 tonnes (tractor of 2 tonnes + cargo trailer of 0.5 tonnes + 5+ tonnes of cargo). Some roads accessing farmland are actually signed with hgv=no. Separated land (road), water, and rail based transportation because they can be treated separately(?). I do not know enough about rail transport, but having only one subkey makes it abit superflous. For additional keys for water transport, see my point on the talk page. boat= should be a master key of motorboat= and sailboat=, and add fishing_vessel= and ship= as master keys as well, all other values suggested on the talk page are written hierchally under ship= Yes, there is a big point in separating boats and ships, just as separating mopeds and hgv. * Direction specific restrictions IMO this does not belong on access, but rather on oneway= as they are dictating special condition of the oneway key. * Evaluating access tags There is a list of national specific defaults of the access keys to highway=, I do not remember where it was now, but think the page is linked under 'See Also' Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-br] fronteira estadual
Oi gente O continental shelf e dividido por estado, este indicar que presisamos marcear o fronteira estadual ate o fronteira nacional 22km no mar. Eu nao sei com os municipos, mas o fronteira precicar incluir os ilhas, acho melhor marcar fronteira municipal um pouco no mar (nao no costo) eu viu que os ilhas no baia guanabara nao e incluido nos fronteiras municipais no RJ, e tambem alguns outros ilhas no costo de RJ nao e incluido. No Para o fronteira e o costo nao tem mesmo linha, as vezes o franteira passo no mar, as vezes no terra. Nao sei que o costo fui ajustada ou nao. O frontera nacional e tudo marcada com interolaçao do costo, eu vai corrigir este fronteira quando eu tem um ferramente para marcear direito. Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Atualizações na wiki - organiza ção do esforço
On Fri, 21 Aug 2009 18:54:30 -0700 (PDT), Diogo diogownunes2...@yahoo.com.br wrote: Pessoal, Coloquei algumas coisas na página de discussão do projeto de Sao Paulo: http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Brazil/SP/S%C3%A3o_Paulo Vamos organizar algumas mapping parties para colocar os nomes nas ruas ? Já está tudo desenhado, deve facilitar bastante o trabalho e para conseguirmos mais editores também. Estou pensando em fazer um daqueles banners para dar um pouco mais de divulgação quando estivermos fazendo o mapeamento, mas sai um pouco caro. Estou pensando também em fazer uns bonés com o logo do OSM também, para dar a novos editores que ajudarem no esforço. Um abraço, Diogo Porque nâo faz um high viz vest egual que eles tem no inglaterra? ( http://wiki.openstreetmap.org/wiki/Image:Sunderland-party-030509.jpg ) Nâo lembra agora mas um usario no inglaterra tem estes por vende, poder fazer mesmo coisa aqui. O vest tem um logo e Surveying for OpenStreetMap no costa. -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Lane turn restrictions
On Fri, 21 Aug 2009 07:48:18 +1000, Roy Wallace waldo000...@gmail.com wrote: On Fri, Aug 21, 2009 at 6:11 AM, Tobias Knerro...@tobias-knerr.de wrote: I believe it fits the project's general spirit to allow mappers to choose their level of detail (and other mappers to increase it if they are ready to invest the time). +1 Lod steps could be described as 1. road without lane detail 2. road with partial lane data (think cycleway=lane) 3. road with full lane data, but no lane geometry 4. road with full lane data and partial lane geometry (e.g. individual ways only for pavements and bicycle lane, but not for the perfectly parallel car lanes) 5. road with full lane data and geometry So, the question becomes, which of the above are already achievable/in use with existing tags, which are in proposal stage, which need new proposals. And then back to the question, how to model LTR (lane turn restrictions) for ways with each of the above LOD's (level of detail). Obviously at least LOD 2 will be required. But we may find that it's only possible to model LTRs simply for ways with LOD 3 or above. As I see it, the tag lane=* can give enough information to how to number the lanes, if there are 3 lanes in the same direction number them 1 - 3 Left to Right. A lane turn restriction should be able to use these numbers in the roles in some way, and continue to work the same way as normal turn restrictions. member=someway1 role=from.1 (from lane 1) member=someway2 role=to.3 (into lane 3 of the other way) member=somenode role=via (the intersection) This approach shouldn't require too much complications for rendering, routing, and so on. An editor might even be able to check if the lane exists (with lane=* tag) in the to and from members. For the example previously in this thread, I think some grouping can be done, such as all lanes between two physical dividers should be tagged as one way, and all physical barriers that have a sensible tag should be tagged as such. A small curb and such barriers should not be tagged, but putting two highway=primary + oneway=yes in same direction parallel would indicate something like that. When such models becomes complicated, intersections needs to be grouped in special ways, maybe an intersection relation or an area tag? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Fri, 21 Aug 2009 01:54:23 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/8/20 Roy Wallace waldo000...@gmail.com: I personally use the direction of way for steps ... What about a one-way way that points downhill? For this, incline=* is useful. It's also more explicit. for ways it is indeed a plus. I was referring just to steps. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk incline should hold a numeric value, to indicate how steep it is, positive value is up, and negative is down, if steepness isn't trivial, leave it out. If you just want to render a steep road sign, why not find out (roughly) how steep the incline is, and tag it with that numeric value? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Lane turn restrictions
On Wed, 19 Aug 2009 15:01:24 +0100 (BST), Steve Hill st...@nexusuk.org wrote: On Wed, 19 Aug 2009, Peter Körner wrote: What's left to be clarified is how lanes are numbered. I'd suggest to be the inner one to be 1, ascending the more you're going to the border The police tend to number them with lane 1 being closest to the footway (i.e. the left lane in the UK, the right lane over much of the rest of the world). Although there could be something to be said for making it region-agnostic so that satnavs don't have to know what side of the road you drive in a specific region. In Brazil, where lane numbers have been signed (at least where I have seen such signs), the numbering follows the direction you read, i.e. from left to right. Left most lane is 1, and rightmost lane is n. For example when leaving Vitoria, passing the bus station the road is 8 lane for a short bit, with signs saying lane 1, 2 to 5th bridge, lane 3, 4 to bus station and return to centro, lane 5, 6 to 1st bridge, lane 7, 8 to some suburb. Maybe lane numbering is country specific, I don't know. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GSoC End: signFinder
On Tue, 18 Aug 2009 23:02:07 +0200, Stefan de Konink ste...@konink.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Peter Körner schreef: Whooohoow this is so cool! Looks like a lot of Voodoo to me :) As I saw from the samples It doesn't work well on blurred images, so it won't work with sth. like a helmet or a car camera, would it? Camera's are not by default blury, they become blurry if the shutterspeed is too low ;) And for a fully automated camera, the shutterspeed is set by light conditions, i.e. not enough light = blurry pictures -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tag official_name ? (was Multilingual Country-List)
On Thu, 13 Aug 2009 10:56:03 +0200, Pieren pier...@gmail.com wrote: On Thu, Aug 13, 2009 at 3:08 AM, andrzej zaborowskibalr...@gmail.com wrote: The instructions at the top of the pages could also mention the official_name:* tags - I don't know if these are approved in any way but I found they were on some of the nodes and I thought it was a good idea to propagate these too where the full name differs from the normal name the country is known by (which could otherwise be placed in loc_name, but it should probably be the one displayed by default) What is this mess about official_name, name and loc_name ? Is someone shifting what was earlier name/loc_name to something new like official_name/name ? Where is it discussed/described on this ML or the wiki ? Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk official_name could be added without changing the meaning of name. For example, official_name=Kongeriket Norge, name=Norge, name:nb=Norge, name:nn=Noreg, name:en=Norway. Kongeriket Norge is the official name of Norway, though it is commonly known only as Norge and Noreg depending on which form of the Norwegian language you speak. Some cities also have the same. One could also add nick_name to the list, for example the city name=Fredrikstad have nick_name=Plankebyen. In my opinion name should be what you expect printed on a map sold in that country. All other *name* tags and name:* tags should be available for multilingual searches and common aliases. If I search for Kongeriket Norge I expect to find Norway, but would I find Fredrikstad by searching for Plankebyen? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] can search engines index osm data?
On Tue, 11 Aug 2009 12:30:30 +0200, Erik Johansson e...@kth.se wrote: On Sat, Aug 8, 2009 at 11:04 AM, Aun Johnsen (via Webmail)skipp...@gimnechiske.org wrote: There are millions of references to London on the net, while not that many of Pitlochry. That meaning a search for London might not give any OSM returns unless OSM becomes a featured site, while a search for Pitlochry probably will return a OSM link. To use Firefox autocomplete I usually do bookmarks like this: http://osm.org/?lat=56.704lon=-3.733zoom=13#Pitlochry http://osm.org/?lat=59.3211lon=18.0508zoom=12#Stockholm This is imensely usefull for me personally making it very fast to find my frequent places.. For that to work with search engines more people would need to use the same url.. How do you manage that? Another thing that might help is if the OSM maps (www.osm.org / informationfreeway / other?) show the name of large places in the visinity in the title bar of the browser. This should be possible throughdynamic queries in the dynamic html generator (AJAX/php/other). This would make hits on OSM links rank higher in the search engines as it would be both a link pointing to Rome, and Rome in the title of the page it leads to. A metadata field in the html header can even improve this more. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] PDOP, HDOP, VDOP
HDOP is of most interest for you, that is the horizontal delution of your position, that means how far from the logged position on the ground you can be. VDOP is the same value vertical, in other words, the error in the height, and if I am not entirely wrong, PDOP is the entire sphere (make a ball with your possition in center, and you are somewhere inside that ball. DAGE and DSTA I am not too certain about, but think that has to do with age of signal and satellites in view. My advice is to keep HDOP and leave the others. On my checklists at work we note HDOP and EPE (EPE is error eclips, based upon a complicated formula on HDOP, satellite constillation (how they are spread on the sky) and the results of any augmentations). It is not likely that any handheld units can calculate EPE. - On Mon, 10 Aug 2009 09:26:08 +0200, Konrad Skeri kon...@skeri.com wrote: My GPS logger can save PDOP, HDOP, VDOP, DAGE and DSTA precision data. When converting to GPX-track I can exclude points based on *DOP values. 1. Are there any use for DAGE and DSTA? (I have them disabled - enableing them decreases the estimated trackpoints in memory by 16%) 2. Which of the *DOPs are useful for this kind of filtering. 3. Do you happen to have some suggested values of *DOP when not to include the trackpoint? regards Konrad Skeri ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] can search engines index osm data?
On Sat, 08 Aug 2009 09:49:17 +0100, Lester Caine les...@lsces.co.uk wrote: David Earl wrote: Lester Caine wrote: maning sambale wrote: For example, I search a POI in G and it points me to an OSM node. The simple answer has to be no. But the complicated answer is yes: in that I am working on the namefinder index to make it available through URLs (and a set of gazetteer pages). Though the first step is to get the index updated again, which is proving to be hard at the moment. But that will only provide what you include in the namefinder? And given the crap going on in most search engines, it's unlikely the results will be displayed anywhere near the top with just a single text match? Google uses algorithms to vectorize how reliable a source of information is, and given its name and how it is built, namefinder might get a prety high score. I guess most modern search engines have the same approach as google to make the most interesting searches appear at the top of the list. Of course there will be a difference in the occurance of a big place compared to a little place. There are millions of references to London on the net, while not that many of Pitlochry. That meaning a search for London might not give any OSM returns unless OSM becomes a featured site, while a search for Pitlochry probably will return a OSM link. A wiki page describing the mapping progress of a place such as Pitlochry will even more increase that chance, and with even firther and more advanced algorithms, google can choose to group similar search phrases with almost identical possitions, so that it doesn't matter if the links to London points north or south of the Thames. The question then is how far have Google and other search engines come in enhancing such algoritms? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] radioactivity
On Sun, 9 Aug 2009 00:42:37 +0200 (CEST), Stefan de Konink ste...@konink.de wrote: On Sun, 9 Aug 2009, Frederik Ramm wrote: Forgive my scientific ignorance, but are actual measurements even static enough - I mean, if I measure radiation X at a certain place, is there reason to believe that it will (in the absence of catastrophic events) be more or less unchanged one month in the future? It depends on the decay time. I just wanted to reply we would require some sort of temporal database to actually facilitate this. So to answer your point. If there is an actual measurement of lets say N amount of becquerels, you can be pretty sure it is more fixed then your typical roads. And if it is dangerous all depends on the type of radiation it emits :) So if we take normal uranium it will only be alpha radiation, unless you eat, breath in dust etc. it is not harmful. (So you know exactly the reason why you shouldn't eat mushrooms in East-Europe) To equip your GPS device (the satelite already has a detector ;) with a Geigercounter will probably give nice information, usefulness within OSM - 0. Just fork it into a thing like the altitude maps. ORM ;) Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Exactly my point. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] to all potlatch and JOSM users - automatic simplification of geometry
On Sat, 8 Aug 2009 14:42:43 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: Hi all, I want to point attention to the potlatch-funtion tidy-points (similar to JOSM simplify way). I encourage everybody not to use these functions (at least not on data someone else entered) as it harms severly the data. IMHO OSM is a project about drawing a collaborative map, not about computers drawing it. They don't know the world, e.g. don't know and can't know, where there is a curve and where the street is straight. But what is a straight line? I have seen different results of straight line depending on projection and on line calculation. For example, UTM Straightline, Great Circle and Rhumb Line makes different straight lines, and they look different on UTM, WGS84, ED50 or other projections. The computerised organization, does it make a straight UTM straight line or a straight Rhumb Line? (I guess they do not try Great Circle) And does it calculate to some certain predefined datum, or the active datum in your JOSM preferences? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Mapas de Poço das Antas - RS
Arquivos .dwg e muito usado pelo survey. O uso que eu cohencer e com projeção do UTM, não cohence outros projeção no este formato do arquivo. Voce ja consigue ler os arquivos? Possisoes de UTM sempre e marcada com E (leste) e N (norte), tambem aqui no Brasil. Acho existe ferramente que poder extratar dados do .dwg e tambem coverter UTM pela WGS84. - On Thu, 6 Aug 2009 14:02:45 -0300, Rodrigo de Avila rodr...@avila.eti.br wrote: Boa tarde, Recebi da Prefeitura Municipal de Poço das Antas, no RS, arquivos com mapas do município, como contribuição para o osm. Mas os arquivos tem a extensão dwg e .cdr. Alguém já trabalhou com estes tipos de arquivo, para ficar usáveis no JOSM? Se sim, como fez? Grato. -- Rodrigo de Avila Analista de Desenvolvimento +55 51 9733.3488 • rodr...@avila.eti.br • www.avila.eti.br -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 09:24:55 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Mon, 3/8/09, SLXViper slxvi...@gmx.net wrote: quadcopters/hexacopters/octocopters/microcopters equipped with a camera are much better than a satellite. Easier and cheaper to use, and most important: satellites give only rather poor quality images, often with lots of clouds... Digital orthophotos and the high resolution imagery of google (and others) are made from planes, not from satellites. Some sort of decently sized blimp would probably be cheaper to run and don't need to constantly use energy to stay above the ground. I wonder if you can get a cheap second hand blimp from somewhere... OSM Zeppelin finally moored up at Empire State Building? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 09:36:47 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Mon, 3/8/09, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: OSM Zeppelin finally moored up at Empire State Building? What would the good of that be, it should be out mapping! Stocking up on supplies and crew for a whole year of mapping of course :D Need her operating non-stop 24/7 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 01:29:19 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Sun, 2/8/09, Michael Kugelmann michaelk_...@gmx.de wrote: The article also says: It has three-quarters of the mass (0.75-kg) and volume of a CubeSat = quite small and the capacity will not be suficcient for appropriate lens/camera. And I'm shure it is not 3 axis stabilisation = no alignment to the desired target. If someone can rectify images taken out the side window of a plane as it comes in for landing, and taken by astronauts on the space station they could probably rectify images from a sat without stablisation. Somebody please host the WMS But it can also result in an OpenLunaMap :D -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 01:47:23 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Sun, 2/8/09, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: But it can also result in an OpenLunaMap :D You'd also get a star map too ;) Hubble go home, I have a compact cam :D -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Sat, 1 Aug 2009 00:22:40 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/8/1 Renaud MICHEL r.h.michel+...@gmail.com: Le vendredi 31 juillet 2009 à 03:23, Roy Wallace a écrit : What about a way that has either a physical limitation or a legal limitation (not both). Perhaps there is some argument that the tag should differentiate between these situations? Though I admit I can only think of a weak one - that it makes it clearer for users and mappers I have a very good example: For an ambulance, many legal limitations (like speed limit) don't apply, so if a road has a legal limitation for the maximum height of 2m but you can actually physically take that road with a 3m ambulance, that is a useful information for the ambulance driver who then knows he can actually take that road, although regular users may not. This is a nice theory, but can I see some example? I doubt that there is any bridge with 3 m height and 2 m restriction. And I doubt that the ambulance driver would (in case of emergency) have the time and nerves to check if a bridge with 2m- restriction will still have enough space for him to pass. And I won't recommend him to rely on OSM data. Can you imagine what happens to him, if he gets stuck under a bridge with designated maxheight (and he's bigger) with an emergency patient on board? I don't neglect the usefullness of this tag though: there might be special transports (accompagnied by local police) that might pass (with special permission and controll) a bridge that legally is restricted e.g. to 2,80 but physically allows even 3,00 m to pass. They will even get rid of some air in their tires if it is needed ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk 1) height restrictions are not only placed on bridges, but also on tunels, where low wires hang across roads, or other physical barriers. The difference between physical and legal limitations I do not know about, and I guess one would have to go around with a measuring tape to find it out. 2) ambulance drivers are usually guided from traffic centrals, where they use routing software and traffic monitoring actively to find the quickest way. The ambulance drivers are usually on radio contact with these centrals during the entire trip to the cashualty and back to the hospital -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Tagueando Motéis
pensando os outros ícones do hoteis, moteis e pousadas, poder ser uma cama com uma cooraçaozinho rosa-pink :D On Sat, 1 Aug 2009 08:41:24 -0300, Claudomiro Nascimento Junior claudom...@claudomiro.com wrote: Já poderíamos pensar num ícone para o mapa... um coraçãozinho ? :-) 2009/8/1 Arlindo Pereira nig...@nighto.net: Galera, criei uma proposta de tag amenity=love_hotel, vejam a página http://wiki.openstreetmap.org/wiki/Proposed_features/Love_Hotel a motivação reside no fato de que o que chamamos de motel aqui no Brasil é completamente diferente do que se chama de motel no resto do mundo. Em inglês, motel vem de motor + hotel, e significa simplesmente um hotel com garagem, sem a conotação sexual que temos aqui. Se quiserem, podem comentar algo em inglês (para não ficar restrito à nossa lista) na página de discussão da tag proposta em http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Love_Hotel [] -- Arlindo Saraiva Pereira Jr. Bacharelando em Sistemas de Informação - UNIRIO - uniriotec.br Consultor de Software Livre da Uniriotec Consultoria - uniriotec.com Acadêmico: arlindo.pere...@uniriotec.br Profissional: arlindo.pere...@uniriotec.com Geral: cont...@arlindopereira.com Tel.: +5521 92504072 Jabber/Google Talk: nig...@nighto.net Skype: nighto_sumomo Chave pública: BD065DEC ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] limites municipais: admin_level
On Sat, 1 Aug 2009 12:57:16 -0300, Eduardo Habkost ehabk...@raisama.net wrote: On Sat, Aug 01, 2009 at 09:08:15AM -0300, Claudomiro Nascimento Junior wrote: Acho que as meso e micro regiões não tem conotação nem política nem adminsitrativa - na verdade, esse conceito é pouco usado fora do IBGE - que agrupa os municípios nessas divisões em algumas tabelas estatísticas geradas. Comparando com os outros países o nível 6 parece mais adequado para os nossos municípios e isso é o que importa agora para o trabalho de importação de limites - o nível 4 para estado parece que já está no consenso. Pode dar algum exemplo em que o equivalente a município em outros países está no nível 6? A maior parte dos países parece ter o equivalente aos nosso municípios no nível 8. Por exemplo: eu acho que um município no Brasil é muito mais parecido com city e town dos EUA que com county. A maioria dos outros países que vi usa municipality (= município) no nível 8. E, uma coisa é deixar de usar níveis e remover/adicionar itens da tabela, outra é querer mudar os números já usados. Que mal faz uma coluna em branco na tabela? Ter uma folga para poder inserir/remover níveis no futuro é até mais flexível. O importante é ter uma convenção, (afinal de contas é só um número), e o número 8 para municípios já está ali há muito tempo. Mas acho que a grande questão é: já existem fronteiras municipais mapeadas no Brasil? Vamos estabelecer que quem quiser propor mudar o nível de municípios de 8 para 6 vai ter que escrever o script que vai mudar as fronteiras existentes? ;) Um outra pergunta, que e mais probable, no futura adicionar mais diverçoes do municipo ou adicionar outro niveis administrativo acima do municipo? Au achou que nos poder verno maximo um ou duas niveis administrivo dentro o municipo, mas tem mais probabilidad para ver outro niveis acima. Por exemplo os estados São Paulo e Rio de Janeiro poder beneficar com um divicoe regional. -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapeando bairros (era Re: limites municip ais: admin_level)
On Sat, 1 Aug 2009 16:18:03 -0300, Eduardo Habkost ehabk...@raisama.net wrote: On Sat, Aug 01, 2009 at 07:57:35PM +0200, Aun Johnsen (via Webmail) wrote: snip Acho que distritos e sub-prefeituras poder ser mesmo nivel, mas com estrutura diferente. Sub-prefeitura ja e um parte dos metropolos sao paulo e rio de janeiro, mas acho que mesmo nivel no guarapari vai chama distrito. Concordo. Não creditar que bairros e nivel administrativo. Qual seria o jeito certo de mapear limites entre bairros dentro de municípios? Há uma convenção existente para esse caso? Aqui eu não tem certesa. Acho que no alhemao eles usar boundary=administrativ, mas eu nao cohencer um bairro com um administraçao. Eu nao sei boundary=political e melhor, porque ninguem documentou este no wiki. Tambem viu um proposal por named places ou name usage que sugeçou usa fronteiras pela os nomes locais. Tambem poder ver no postal_code, onde poder dizer que os bairros tem mesmo relaçao com codigos postal no Europa. -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Fri, 31 Jul 2009 10:59:27 +0200, Pieren pier...@gmail.com wrote: On Fri, Jul 31, 2009 at 6:56 AM, Roy Wallacewaldo000...@gmail.com wrote: On Fri, Jul 31, 2009 at 2:40 PM, Cartinuscarti...@xs4all.nl wrote: For three reasons: 1) In the part of my e-mail you did not quote I just pointed out lots of people don't read those definitions. The difference between the words maxheight and maxheight:physical is not explicit enough. 2) Because the old definition of maxheight didn't explicitly state it was a legal and not a physical limitation. Just changing the definition now doesn't magically transform all the places where people already tagged a physical maxheight with the maxheight tag into a maxheight:physical tag. At least not until somebody invents a mindreading osm-bot. 3) The people who do not care/know about the difference are still going to tag a physical maxheight with the maxheight tag. The endresult is that you will never know whether something tagged with just maxheight is a physical and/or legal limitation. +1 No, no, no. maxheight until now was clearly the legal maxheight. It is not explicitely writen on the wiki because you don't see the physical height in many countries here in Europe but only the legal traffic sign and the max height traffic sign is displayed on the Map Features page since january 08. I don't find any controversy about this interpretation in the archives on this ML, so we can assume that maxheight was until now the legal maxheight. We just need to clarify this point on the wiki and add a new tag for the physical maxheight for countries where it is available (call it maxheight:physical if you want) Pieren No, you can only ASSUME that the current maxheight only use the legal form. Have you counted usages in countries where the physical maxheight are signed? Do you even know which countries such signs are available? Without any statistics, you cannot know. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Fri, 31 Jul 2009 15:33:53 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/7/31 John Smith delta_foxt...@yahoo.com: Some of us are in Australia and there will only be one sign posted in Australia which is the legal height, but the person you are responding to is in Brazil and you said none for South America so that answers that I guess. there were no occurrences by 23th of July 2009, maybe in the meantime someone added one or two ;-). I added the word legal to the maxheight definition and ask anyone interested and familiar with those additional physical-height-signs to set up a page (might contain an explanatory photo, but his could also be added later). Can be also very short, but I don't want to loose the outcome of this discussion as often happens in OSM. http://wiki.openstreetmap.org/index.php?title=Key:maxheight:physicalaction=editredlink=1 cheers, Martin Two reasons I have not made a description of Key:maxheight:physical yet 1) http://wiki.openstreetmap.org/wiki/Proposed_features/clearance My proposal page, I'll let that process go, with input bouth from the wiki and the mailing list 2) I am stuck at work for another 4 weeks with a slow, unreliable, and limited internet connection, so my time on internet is very limited When the process is completed, I will also make brazilian translations of Key:makheight any variation of maxheight that will be implemented. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Thu, 30 Jul 2009 14:17:22 +1000, Roy Wallace waldo000...@gmail.com wrote: On Thu, Jul 30, 2009 at 12:00 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Wed, 29/7/09, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: I have made a proposal for a tag ... I think this will only serve to confuse, no where on the maxheight wiki link you provided does it say it's a legal restriction, if anything it's exactly the same thing you're just giving people the option of picking tags so half the system will have maxheight used, and half will have clearance and the routing software will end up with twice the work for no benefit. True, maxheight currently does not specify the reason. So the question is, is there a need to differentiate between different kinds of maxheight? Surely this issue has come up before in relation to other keys? If there is in fact a need to differentiate, what's the most common practice? For example, maxheight:physical=* and maxheight:legal=*? Just throwing ideas around, but you would first need to demonstrate that maxheight is not sufficient. There area also other possible usages of a clearance tag, such as the free sailing height under a bridge, the height of a footway tunnel and probably much more. Since many countries have two different signs for max legal height and max physical height, and its usages can be very different, why not allow this in tags? By saying that there is no difference between maxheight and clearance is for me the same as saying there is no difference between highway and cycleway, tourism and historic. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Thu, 30 Jul 2009 10:17:02 +0100, Gervase Markham gerv-gm...@gerv.net wrote: On 30/07/09 09:26, Aun Johnsen (via Webmail) wrote: much more. Since many countries have two different signs for max legal height and max physical height, and its usages can be very different, why not allow this in tags? Can you provide sample images for such signs? I confess I find it hard to believe. See on the talk page of the proposal, the two variants used in Brazil is shown there as a response to Lulu-Ann's question on the discussion. The maxheight for a feature such as a bridge is the maximum height of an object of the standard type that will fit under it. So for a road bridge, it would be a bus or truck of the normal 1-lane width. That's the thing people are interested in. If there's a sign which says the max physical height of a truck you can get under this bridge is 11 feet, but legally the max height for this bridge is 12 feet, how is the second piece of information useful in any way? For unicyclists? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Thu, 30 Jul 2009 10:41:11 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Thu, 30/7/09, Martin Koppenhoefer dieterdre...@gmail.com wrote: actually even though the definition in the wiki might not specify it unambigously and explicitly the current use of maxheight These things should be explicitly stated, otherwise people interpret it differently :) (as discussed intensively at least on German ML) should be That doesn't help anyone else not on that list. maxheight:legal, so I would encourage to put it the other way round: maxheight and maxheight:physical Either way, expanding the existing tag makes more sense than creating 2 differently named tags which will cause even more confusion and duplication. Either somebody make it clear how ALL usages of maxheight are to be used, wether legal, physical, marine, or any other special interest usage, or I will continue on my proposal. Without any clearification on the existing tag, than it will be more confusing than adding new tags. I have atleast stated in the definition of the tag how it is to be used. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Fri, 31 Jul 2009 09:25:17 +1000, Roy Wallace waldo000...@gmail.com wrote: On Thu, Jul 30, 2009 at 8:41 PM, John Smithdelta_foxt...@yahoo.com wrote: Either way, expanding the existing tag makes more sense than creating 2 differently named tags which will cause even more confusion and duplication. I agree. So, how about maxheight:physical, maxheight:legal, and leave room for others if there is a demonstrable need in future? I am tempted to suggest maxheight:physical:bridge, maxheight:physical:trees, etc., but that is probably unnecessary at this stage. If this is your suggestion to solve this, than I suggest you do something about it and get that information on the maxheight documentation. I am not sure how you intend this to be done. When you have a process going, point me there, the current documentation on maxheight does not support the needs for me, so my solution was to make another tag. I havn't seen you do more about it than to attack my attempt to solve this. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Fri, 31 Jul 2009 10:45:50 +1000, Roy Wallace waldo000...@gmail.com wrote: On Fri, Jul 31, 2009 at 10:16 AM, Aun Johnsen (via Webmail)skipp...@gimnechiske.org wrote: I agree. So, how about maxheight:physical, maxheight:legal, and leave room for others if there is a demonstrable need in future? .. If this is your suggestion to solve this, than I suggest you do something about it and get that information on the maxheight documentation. I am not sure how you intend this to be done. When you have a process going, point me there, the current documentation on maxheight does not support the needs for me, so my solution was to make another tag. I havn't seen you do more about it than to attack my attempt to solve this. Sorry if I've offended you, Aun - I didn't mean to attack your attempt, and I admire your pro-activity in creating the clearance proposal. I agree with you that the current documentation on maxheight is insufficient. I'm just using this list as I thought it was meant to be used - to get some discussion going and see if we can reach some sort of a consensus before going to the next step of wiki documentation. So, I repeat my question: what do you and others think? Do you think maxheight:physical and maxheight:legal is better or worse than maxheight and clearance? You can call it apples and oranges for me, but it have to be documented. Either by improving the documentation on existing tags, or as I am doing proposing a new tag. I do not know if clearance is the best word, or if other words can describe it better. English isn't my first language, so any linguistic makeup must be applied from some of you that know the language better than me. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - Maritime borders
Ok, I am revisiting this. Both me and Gustav F (original writes of the proposal) was not satisfied with the outcome of the last vote (about 50/50), so I have rewritten the proposal based on many of the comments from the rejecting votes. There was mainly two issues of the rejecting votes: 1) The proposal didn't clearly state what part of the maritime borders belong to relations, I feel this is better stated now. 2) Many people objected to the teritory border being tagged as boundary=maritime instead of boundary=administrative + maritime=yes. This have now been changed too. I am now pushing this for a new vote as no further inpute have come for several months. I hope we can have this approved and get maritime borders put on the map. Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
On Fri, 31 Jul 2009 01:04:37 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Thu, 30/7/09, Roy Wallace waldo000...@gmail.com wrote: different. This, I would argue, is a reason to allow for the How much does the physical height exceed the legal height in most cases? possibility to differentiate between maxheight:physical and maxheight:legal. If maxheight already implies the legal height there is no need to make things convulted for the sake of it, otherwise we'd be typing denomination=the_church_of_jesus_christ_of_latter-day_saints For countries that have different signs for legal maxheight and physical maxheight, you can have a section of road preventing tall vehicles from passing, but they can still legally enter the road (and get stuck?!?). In most cases, it wouldn't be needed when the legal limit is in place, though (at least some) tunnels might have different heights depending on lane (the legal limit might be the central lane, and lower physical height in left and right lane). I am not trying to tag the difference between a catholic church, and a catholic church with a liberal priest, I am trying to tag what I see signed on roads. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging Love Hotels (Brazilian Motels)
On Wed, 29 Jul 2009 23:17:59 +0200, Ulf Lamping ulf.lamp...@googlemail.com wrote: Joseph Scanlan schrieb: On Wed, 29 Jul 2009, Martin Koppenhoefer wrote: Well, I would tag them completely differently. It is a different kind of object, it is not a Motel where you just pay according to a different fee system / business modell. Around here I would not use a separate tag. No-Tell Motels must show a little discretion. Hourly rate is a pretty clear hint as to what people are doing there (not sleeping) but it still looks like a motel on the outside. Places that are more open could very well have businesses that deserve a special tag. For example, I wouldn't tag any business in Clark County as a brothel, the brothels look like other businesses and the prostitutes will go somewhere else when the location draws too much attention from law enforcement. In other Nevada counties, were prostitution is legal, a brothel tag makes sense. These are clearly labeled, well established businesses. Just my point of view from a rather atypical city in the US desert south west. You seem to think about an inofficial brothel, as prostitution is illegal in some parts of nevada. IIRC the brazilian love hotels are often used by regular couples (so probably no business involved). Because the couple still lives at their parents, not married, or whatever. IIRC, this kind of motel is also known in japan. Yes, I guess it makes sense to tag them special, as a normal traveller probably wouldn't want to stay there. As we already have amenity=brothel, why not use amenity=love_hotel for this? I think in most cases they can be tagged as normal motels, most of them also offer day-rates or even week-rates in addition to hour-rates, most of them have a few or more Adult tv-channels, but so do many hotels. The only difference is that some of them have a 18year limit for guests (no minores under 18 can stay). The kind of rates a motel (or hotel for that matter) should be possible to tag, I do not think the entertainment package is of interest to the map, age limits might be tagged as some sort of restriction. I also know that there are normal hotels that have some restrictions, such as no infants, unmarried couples cannot share room, no alcoholic beverage, etc. IMO, a brazilian love hotel should be tagged motel, with additional tags if needed. Me and my wife use such love hotels at times to get a night from the kids, so there are several usages. When travelling in Brazil, usually Pousada is a good and cheap place to stay, taking the role of motels in Europe, though most pousadas don't accept visitors after a certain hour (without prior notification/reservation) while the motels accepts visitors at any hour. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Clearance
I have made a proposal for a tag marking physical clearance over roads, this because it is not the same as legal restrictions on height, and in many countries have a different sign warning the driver that he might not be able to pass, though he still not is legaly restricted. The proposal can be found on http://wiki.openstreetmap.org/wiki/Proposed_features/clearance [1] Brgds Aun Johnsen via Webmail Links: -- [1] http://wiki.openstreetmap.org/wiki/Proposed_features/clearance ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-br] [tagging] Feature Proposal - RFC - Clearance
I have made a proposal for a tag marking physical clearance over roads, this because it is not the same as legal restrictions on height, and in many countries have a different sign warning the driver that he might not be able to pass, though he still not is legaly restricted. The proposal can be found on http://wiki.openstreetmap.org/wiki/Proposed_features/clearance [1] Brgds Aun Johnsen via Webmail Links: -- [1] http://wiki.openstreetmap.org/wiki/Proposed_features/clearance ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] maxheight/height
On Tue, 28 Jul 2009 08:25:34 +0200, marcus.wolsc...@googlemail.com wrote: On Tue, 28 Jul 2009 00:22:54 +0200, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: I do not agree that they bouth should be treated as maxheight=* If my car with load that is 3m high, and maxheight=3m, but physical clearance is much higher,than you would pass at the speed limit, but if both maxheight and physical clearance is 3m, than I would need to slow down to almost crawl when passing the lowest point. maxheight can be 3m even if physical clearnance is 3.2m I am not using maxheight in any of the metrics that involve a travel-time to optimize for so it has no effect on the route other then allowing or disallowing that path at all. Thus at least for me it makes no difference. Marcus It makes no difference for your routing software, but maybe I will make a routing software with that option? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
maxheight=* refers to legal maxheight, in some countries, such as brazil, there is a difference on legal height (restriction) and physical height/clearance (information sign). See my note on the discussion on the wiki key:height - if height is not to be used for this, than another tag is needed - On Mon, 27 Jul 2009 08:57:23 + (GMT), John Smith delta_foxt...@yahoo.com wrote: I've noticed some people have tagged bridges with height=*, rather than tagging the road way under the bridge as maxheight=* and I'm kind of unsure which is better. By using height you don't have to break the way under the bridge up, on the other hand maxheight is specific to the road under the bridge. That all said I think height was a predecessor tag to ele and then again I've seen trees tagged with a height too. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
On Mon, 27 Jul 2009 11:44:44 +0200, Peter Dörrie peter.doer...@googlemail.com wrote: On Mon, Jul 27, 2009 at 11:31 AM, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: maxheight=* refers to legal maxheight, in some countries, such as brazil, there is a difference on legal height (restriction) and physical height/clearance (information sign). See my note on the discussion on the wiki key:height - if height is not to be used for this, than another tag is needed - in Germany you will often find height above sea level written on signs for Motorway-Bridges so height=* is not very clear. I think it would be better to attach this information to the street, not to the bridge because it is the street that is influenced by this. and you could argue that in those cases the legal height is identical with the physical height. Greetings, Peter height above sealevel should be tagged ele=* and not height=* -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
I do not agree that they bouth should be treated as maxheight=* If my car with load that is 3m high, and maxheight=3m, but physical clearance is much higher,than you would pass at the speed limit, but if both maxheight and physical clearance is 3m, than I would need to slow down to almost crawl when passing the lowest point. maxheight can be 3m even if physical clearnance is 3.2m They can even be tagged on the same node. On Mon, 27 Jul 2009 12:14:31 +0200, marcus.wolsc...@googlemail.com wrote: I am tagging both as maxheight. It is a restriction that you are not capable or allowed to pass a given node or a given way in any direction with a vehicle of greater height. That is also how I am evaluating maxheight and maxwidth in Traveling Salesman. Marcus On Mon, 27 Jul 2009 11:31:49 +0200, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: maxheight=* refers to legal maxheight, in some countries, such as brazil, there is a difference on legal height (restriction) and physical height/clearance (information sign). See my note on the discussion on the wiki key:height - if height is not to be used for this, than another tag is needed -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, 28 Jul 2009 10:34:00 +1000, Roy Wallace waldo000...@gmail.com wrote: On Tue, Jul 28, 2009 at 10:15 AM, Cameronosm-mailing-li...@justcameron.com wrote: I think tag the part of the way that is signed. Generally before bridges there is a sign informing road users of the bridge's restrictions. Sometimes they will offer an alternate route for larger vehicles. So tag from the nearest junction if available or the sign. Funnily enough, where I have been mapping the sign is always on the bridge itself. Anyway, I think we should be tagging what the sign is referring to, independent of the sign itself. A clearance tag could just as easily be misinterpreted as the maxheight tag. I don't see how. bridge=yes; clearance=2.8... Roy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk I am writing a proposal for a clearance-tag, I will send it out tomorrow. Link is posted from the tag-height discussion if you want to have a look at the draft -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cheap Recorder
On Thu, 23 Jul 2009 21:47:56 -0500, Ian Dees ian.d...@gmail.com wrote: 2009/7/23 Iván Sánchez Ortega i...@sanchezortega.es Sorry to be off-topic, but has anyone looked in to building the perfect OSM GPS logger from parts? I wonder if the overall price would be less than $40 if we put together a GPS chipset, an SD card slot, and a simple microcontroller. No screen, just one mode: record every second to the SD card. If anybody comes up with a building description for that, than I am more than willing to put it together and do tests. Hack I could make two of them and have one fixed in my car and the other mobile to do hiking trail and stuff. I am currently tracking with an eTrex Yellow, and want something that give me a higher density of points and a better transfer solution than RS232 (would like the stored track to contain HDOP and velocity in addition to position and elevation) -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Do we care if its forest or wood? Natural world mapping ...
On Thu, 23 Jul 2009 20:24:10 +1000, Liz ed...@billiau.net wrote: On Thu, 23 Jul 2009, Tyler wrote: Liz, I would classify most eucalyptus spp. as deciduous (though judging by your genus compositions you're in Australia, and I don't know what the species do there), and probably classify casuarina spp as coniferous... but that's a bad classification system. That's like saying this apple is green, that grapefruit is citrus. There are deciduous conifers, and evergreen broadleafs. Coniferous doesn't even account for all of the needleleaf trees.. The wiki should probably be suggesting deciduous, evergreen and mixed. . . Adopting the UNEP-WCMC broad categories [1] would make much more sense than the current bad wiki suggestions. and adopting the more specific categories would cover a vast majority of forests. The division between coniferous and decidous in Norwegian (european?) maps was originally interesting from an economical point of view, as the value and usage of pine/sprouce lumber and oak/maple is very different. But as OSM might have even more different usages than old trade maps from northern europe, maybe we should tag in a whole different way? As I now live in Brazil, where I have less then halve a clue what the different types are called, the best for me would be to identify the types of wood by what I can see (broadleaf/needleleaf + evergreen=yes/no + tropical/subtropical/temperated/subartic maybe?) -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] i18n-rich areas on the map
On Tue, 21 Jul 2009 22:05:40 +, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: I'm doing some experiments with multilingular rendering (for deploying on Wikimedia sites, see Maps-l) but I'm lacking good test data. What areas on the OSM map are especially rich in name:$code tags for different languages? Preferably down to street level. I would suggest any multi-lingual conflict zones such as Cypros (greek, turkish, english), and countries with several official languages (Belgium). Should be some good opertunities in south-east asia, but do not know how good the data is. Cyprus/Belgium should have a good dataset to work with. I thought Gaza might be pretty good but it mainly just has an odd mix of name:en and name= where the main name tag contains the arabic version too. There should be a name:en or similar for every name written with non-latin characters Are there any areas that are better? Preferably with more than two languages. Try Quibec (Frensh/English), Cypros (Greek/Turkish/English?), Belgium (French/German/Dutch), Switzerland (French/German/Italian/?), Southern Finland (Finnish/Swedish), Northern Norway/Northern Sweden/Northern Finland (Norwegian/Swedish/Finnish/various Samii names), Greenland might also be a source (Danish/Inuit), check also out Thailand, Malaisia, Singapore, Bangladesh, Sri-Lanka, Hong Kong where the names might be written with various types of lettering (Latin/Sanskrete/Chinese) even if the names are the same in all languages. Besides, important cities, such as national capitals should also be available in all variations of the name (Peking/Pequim/Bei Jing/++ for the chinese capital). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] JOSM
On Fri, 17 Jul 2009 22:02:40 -0300, Mauro Borowsky wrote: O que é JOSM? Para que serve? Precisa instalar? Mauro Borowsky JOSM e um editor de mapa que funcionando no qualquer plataforma que tem Java 1.5 instalado. O informacao do JOSM no wiki ainda nao traducido por portuguese, mas nos aqui que tem experience com JOSM poder ajuda com qualquer duvidas. Eu usando JOSM para quase tudo de meu trabalho no mapa. Instalacao do JOSM depende que plataform voce usando, por exemplo no Windows instala Java 1.5 ou mais novo de http://java.sun.com/ [1] baixa ultima josm-stable.jar ou josm-latest.jar de http://josm.openstreetmap.de/ [2] e abre o arquivo jar. Brgds Aun Johnsen via Webmail Links: -- [1] http://java.sun.com/ [2] http://josm.openstreetmap.de/ ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Import IBGE - Restante das Cidades
Oi Eu poder fazer o limpeza do dados no Espírito Santo (mas vai ainda demora um ou dois semanas). Eu viu que algum nodes de cede foi duplicada. Mesmo, eu autualizar os paginas de Espírito Santo no Wiki (que eu poder fazer no trabalho). Ainda esperando os fronteiras munincipais importando. Eu poder fazer tudo os relacãos fronteiras estaudal quando este trabalha completar. -- Brgds Aun Johnsen via Webmail ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova página inicial do WikiProject Brazi l
On Thu, 4 Jun 2009 16:57:41 -0300, Vitor George vitor.geo...@gmail.com
wrote:
Olá pessoal,
Dei uma limpada na página do WikiProject Brazil. As alterações são:
- criação de sub-páginas com projetos, importações, traduções,
etc;
- links interessantes para o mapa do Brasil, como OpenStreetBugs,
OSMaware,
etc;
- criação de um template de links para as páginas das unidades
federativas
do Brasil.
Creio que a página enxugada ajudará em muito a navegação no wiki.
Eu tive que retirar uma tabela de status que existia. Ela estava muito
desatualizada. Minha opinião é de que se tiver que ser feito um
controle
de
status, ele deverá estar dentro das páginas dos estados e/ou das
cidades.
Segue o link do wiki:
http://wiki.openstreetmap.org/index.php/WikiProject_Brazil
Abs,
Vitor
PS: Alguém sabe criar uma versão brasileira para aquele template de
informações sobre locais, o {{place}}?
Eu poder criar o template, mas algum precicar controlar o template quando
pronto (corrigir o lingua)
--
Brgds
Aun Johnsen
via Webmail
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Getting Good Tracks With eTrex
On Wed, 03 Jun 2009 16:52:37 -0400, Paul Houle p...@ontology2.com wrote: I was annoyed to discover that saved tracks on my eTrex Vista HCx don't have timestamps. I did some experimenting and discovered that I need to use the ACTIVE LOG if I want timestamps and control over the tracks. Funny enough, I didn't find this in the manual or online, so I wrote something up at http://gen5.info/q/2009/06/03/getting-a-good-track-from-a-garmin-etrex/ Is there anything else I need to know about getting good tracks? It is like that with eTrex Yellow as well, though there are a few other tweeks to be aware of. My experience is that a saved track have less points than the active log from the same time interval, and also that you cannot set sampling interval, theither in time or distance, it only uses a special formula for when to store a point (fewer points along a straight leg, and more points in the turns). There are many situations where I wished I had a unit that stores a point every second, or that stores to a memory card, but I have to live with my eTrex yellow for now. When travelling, I upload tracklogs to my laptop every day in order to store as many points as possible. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 21:56:09 +0200, andrzej zaborowski balr...@gmail.com wrote: 2009/4/23 SteveC st...@asklater.com: On 23 Apr 2009, at 12:32, Teemu Koskinen wrote: On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via- node using the way. Um... no. The restriction has handedness - left or right... and the way coming off it has an angle.. lets try some ascii B | | |--C | | | A I am going from A to B. There is no 'right_turn' restriction on the corner that stops me turning to C. That cannot be interpreted as a restriction from B to A as it would be a left turn, not a right turn. To figure that out you just need to compute the angle it makes with your direction of travel to see if it's left or right? The no_left_turn, no_right_turn is only to indicate the type of streetsign to show AFAIU. Practically, adding angles to the specification will be a hell to implementers, and there are few use cases that would benefit from this. Sometimes you will have a way splitting off to C that first turns slightly left, enters a tunnel or viaduct and then goes on the other side of AB, something that at low zoom level looks as in your drawing, and the streetsign might stilll be no_right_turn. Or something like this is common: B C \ | \ | \| | | A where the straight line is considered a turn even though it's straight, and the turn from A to B is considered straight even though it's an arc :P Cheers So how do you mean to tag a no_left_turn, where it is marked with a fully drawn yellow line in the center of a road, but no sign? The restriction to tag must correspodent with the actual restriction, so that a routing engine will route you correctly even if there are no visible signs. Sometimes restrictions can be painted in the lanes (one lane with arrow to the right, and one straight ahead, but no lane with arrow to the left). The choise of lane will than correspodent with where you are going, I guess that type of routing might come in another relation. A ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] odd rendering + county boundaries
Maybe the coastal part of the boundary should follow the baseline as per http://wiki.openstreetmap.org/wiki/Maritime_borders The base line is the maritime border closest to the coast, and will probably not be rendered on most maps. --[] On Mon, 2 Mar 2009 11:22:34 +, Thomas Wood grand.edgemas...@gmail.com wrote: I believe that there's some boundary rendering bugs that are yet to be fixed in mapnik, I've not seen this one before. As a side issue, does the county boundary really go up the river like that or just cut across the mouth? I think we need to review this. I recall talking to steve8 who did the boundary relation for the southwest counties that he'd just added the coastline to the relation, and not considered river mouths. I'll look into the data myself if I get the time. 2009/3/2 Kevin Peat ke...@kevinpeat.com: I made some changes a couple of weeks ago to the banks of the River Dart through Totnes http://www.openstreetmap.org/?lat=50.42863lon=-3.67974zoom=15layers=B000FFF Obviously those changes have been picked up as the county boundary is rendering along the updated river bank but the actual river isn't. Is this just a time lag thing or have I done something wrong? On the subject of UK county boundaries it's nice to see them rendering (in Mapnik) but it seems a bit odd for the boundaries to be rendered around coastlines and up river estuaries. Is it possible to only render the inland parts ie. where the ways are not tagged as natural=coastline? thanks, Kevin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - Marketplace
As I havn't gotten more feedback lately, and I think the proposal looks good, I decided to push it to voting today. You can find the proposal on http://wiki.openstreetmap.org/wiki/Proposed_features/Marketplace Please read the discussion before voting, and if you reject the proposal, please give a reason. Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Computing the 12-mile line
I created control lines perpendicular on the coast and used these to find the nodes for the 12-nm line, where the distance to other country was less than 24 nm I used the same technique to find the mereidan line between the countries. I did this along the entire coast of Brazil. I will need to redo it with a script and a position database for baseline, 12nm, 24nm and eez I used JOSM, as I can move around on the map freely, and get lengths of lines as I create them (12nm = 4m) -- On Fri, 20 Feb 2009 23:41:26 +, Thomas Wood grand.edgemas...@gmail.com wrote: I just tagged up the one I found in the database, I attempted to use GIS software to create a section where it misses a scottish island, but failed after 2-3 days of playing, I can't recall who put the data in originally. I'd be interested in seeing any code put into svn for others to use. On 20/02/2009, Adrian Frith adr...@frith.co.za wrote: For those of you who have been adding the 12-mile territorial waters line: did you calculate that data by offsetting the coastline/baseline? And if so, how did you do it? I mean: what software did you use, and how? Thanks, Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Marketplace
Hi I have written a proposal for Marketplace, a regulated area outdoor (or indoor) for trade of various commodities. I have used a couple of days in Draft, but have decided to push the proposal forward to RFC, and if there are few suggestions to improvements I will open it for vote in a couple of weeks. The proposal is found on http://wiki.openstreetmap.org/wiki/Proposed_features/Marketplace I am on purpose omitting any subtags, as these have little to do with the marketplace tag itself. Many subkeys can be used to describe a marketplace, but I feel introducing them might result in long arguments, and long delays before this tag can be approved. -- Brgds Aun Johnsen aka Skippern via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposed Feature/Marketplace coming up, please help me polish this.
Hi After seeing a discussion on talk-br, I found that we are missing a tag for outdoor marketplaces, and made a proposal at http://wiki.openstreetmap.org/wiki/Proposed_features/Marketplace If you could help me get this polished so that we can have it voted for quickly, as this is a feature we need to get in. Most countries have some form or another of this, whether it is a farmers market, a market for crafted goods, or souvenir shops on the street. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Mon, 9 Feb 2009 11:07:17 +, 80n 80n...@gmail.com wrote: On Mon, Feb 9, 2009 at 10:57 AM, Gustav Foseid gust...@gmail.com wrote: On Mon, Feb 9, 2009 at 10:49 AM, Jochen Topf joc...@remote.org wrote: Actually the best we have is the actual tagging in the database. Works wonderfully. I disagree. Can you show me how to make rendering rules (I am mostly interested in Mapnik, but any renderer will do as a proof of concept), which does not draw a border line along the coastline of Germany and at the territorial waters border of Germany? Tagging the appropriate parts with maritime=yes or something would add valuable semantic information about these borders. It would also then make it very easy for renderers to suppress them or render them differently. 80n Which doesn't solve how to tag baseline, contingency zone and exclusive economic zone. Aun Johnsen (via Webmail) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maritme borders
On Mon, 9 Feb 2009 20:44:38 +0100, Jochen Topf joc...@remote.org wrote: On Mon, Feb 09, 2009 at 07:24:00PM +0100, Aun Johnsen (via Webmail) wrote: Maritime borders are by their nature different from administrative borders on land, so I think that using boundary=maritime rather than boundary=administrative maritime=yes (or other suggested options) is worthy. Why are they different? I don't see that. Adding new tags (here boundary=maritime) always has a cost. Every software that wants to do something with the data has to know about it. Jochen Why should we refuse to add boundary=maritime? Do you have a better suggestion for baseline, contingency zone and exclusive economic zone? And why should the maritime territorial border be trated differently than the ones I mentioned? Isn't tagging admin_level enough to link it with other national/administrative borders? Oh, I don't mind how you do baseline, contingency zone and exclusive economic zone. The only thing I am saying is that administrative borders are the same whether on land or on the sea. So they should be treated the same way. And admin_level is not enough in my opinion. The deciding tag is boundary=administrative. Well, actually the deciding thing is the same tag on the relation. Maybe we should have named it administrative_boundary_level=# . Then we'd only have one level. But we didn't and there are already many, many boundaries out there tagged that way. But you have a point there. Maybe we should just use admin_level and ignore the rest? Jochen You mean to say that admin_level is ONLY used on boundaries? I have seen at least a dousin other usages of admin_level. Besides, the way I suggested it in Proposal 3 allows for clean and simple tagging, and doesn't make it difficult for rendering software to choose if they want to render maritime borders or not. The point in tagging maritime borders is to give access to the information, and that gives reason to clearly differ between borders at sea and borders at land. Whether there is a difference between them or not is not up to us, but to those who choose to use the data, and that is reason enough to tag them different. Yes it can be done by adding maritime=yes to an administrative border, but I really don't see the point in treating the territorial border differently than baseline, contingency zone, eez, and what other maritime borders that we might decide to enter. If you are not happy with Proposal 3, write your own, you are free to add it to the rest of the proposals on Maritime Borders. -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
