Re: [OSM-talk-be] Question about speed limit rules in Belgium
Maarten Deen wrote: Just a quick question: In Belgium, normal 2-lane roads have a maximum speed of 90 km/h. In more populated areas and on hazardous points, the speedlimit is lowered to 70 km/h by a sign. How for does this speedlimit reach? In the Netherlands the rule is that outside villages, a speedlimit is valid for a roadsection, which is until the next crossing or junction. Is it the same in Belgium, so if I don't see a speedlimit sign after a crossing, the speedlimit is not valid anymore? A speed limit signed with a traffic sign (e.g. C43), and without zonal application, is valid until the next junction. This is not limited to outside villages (and neither is that so in The Netherlands, by the way). Vanaf het verkeersbord tot het volgend kruispunt, verbod te rijden met een grotere snelheid dan deze die is aangeduid. A partir du signal jusqu'au prochain carrefour, interdiction de circuler à une vitesse supérieure à celle qui est indiquée. Wegcode / Code de la route, Art.68 http://www.wegcode.be/wet.php?wet=1node=art68 http://www.code-de-la-route.be/wet.php?wet=1node=art68 -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] list of usefull links and tools
Johan Van de Wauw wrote: Kwa hoogte zou ik eerder gebruik maken van de zopas (eind juni) vrijgegeven aster-data. De resolutie (en kwaliteit) daarvan is een pak beter dan van srtm. http://asterweb.jpl.nasa.gov/ Er zijn nog twijfels over de toepasbaarheid van ASTER binnen de licentie van OSM. Daar probeert men nu duidelijkheid over te krijgen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Mapping GRs?
Peter Bienstman wrote: Hi, A project that is of interest to me is mapping out the GR footpaths, as described in: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walking_Routes Great! But did you find any missing ones? We have so many entered in Belgium already. :) However, I was wondering if we are legally allowed to do so. Our French Yes, sure, go ahead. friends don't seem to think so: http://forum.openstreetmap.org/viewtopic.php?id=3665 Or is the situation in Belgium different? The situation in France isn't different, it's just that they're collectively scared of adding *publicly* marked routes into OSM. What would happen if I were to spend a holiday in France, and mapped a bit of GR and put it in OSM? Would they delete it? If they did, I'd just put it back. And back... and back. It's facts, people, nothing else. The only issue that could come into play is a trademarked or otherwise protected name. Fair usage also comes into play, then. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Foutieve mapping
Lennard wrote: Verzoek aan iedereen er even vanaf te blijven, zodat het terugdraaien goed kan lukken. Het herstellen lijkt goed gelukt, maar het is mogelijk dat er nog een verloren node in de db staat. Dit was trouwens weer een voorbeeld van de Live Editing mode in Potlatch. Beter kies je voor Edit with save als je wat wilt uitproberen. Vroeger stelde Potlatch de vraag of je in probeermodus wilde werken. Dit was een explicietere vraag dan de huidige Live vs With save, die voor een beginner nietszeggend is. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Foutieve mapping
Leon Vrancken wrote: Weet iemand hoe je dit kan stoppen? Er is een escalatieprocedure voor dit soort gevallen. http://wiki.openstreetmap.org/wiki/Vandalism Deze volledig doorlopen kan dagen tot weken in beslag nemen. Echter, in dit geval was het duidelijk genoeg dat het volslagen foutieve edits waren, en heb ik nu deze changeset teruggedraaid. De procedure kun je echter gewoon doorzetten, want het lijkt aannemelijk dat dit niet de laatste edit van oland1750 zal zijn. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] EGNOS works, mail to the EU??
Marc Coevoet wrote: Hi, Since 1 oct, Egbos is available (is the EU variant of the GPS system). It is not (the EU variant of the GPS system). It is an augmentation system for the existing GPS system. Would it be an idea to mail Mr Antonio Tajani, European Commission Vice-President for Transport Policy, to obtain the EU map data, like it happened in the US?? There is no 'EU map data', but feel free to mail him. you don't have to pay taxes, until the data is free. I will not recommend that you try, but I also won't stop you. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] herinnering Antwerps OSM Cafe zondag 25 oktober
wannes wrote: Okido. We kunnen toch nog niet routen afaik, dus gaat er ook niemand verloren rijden. http://yournavigation.org/ http://www.openrouteservice.org/ http://www.cloudmade.com/products/routing -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] abandoned railways
But about visibility: it's a choice of the people in charge of the rendering. You could open a trac ticket to ask for a change as I don't think there's anyone on this mailing list who can edit the rendering rules directly. You would be wrong, but please still open trac tickets for requests, to have all requests in a single channel. railway=abandoned/disused/construction rendering was reinstated on 8 October, after I forgot to add that when doing some earlier work. That's what Ben was alluding to, when he said they were on again/off again on the map. http://trac.openstreetmap.org/changeset/18021 -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] abandoned railways
Luc Van den Troost wrote: Perhaps you can explain how 'abandoned' and 'disused' SHOULD be interpreted in relation to the rendering rules. As far as I have seen, the wiki pages about railways do not mention this. I can only explain at the moment how these situations handled on the mapnik map. How they *should* be shown, is another matter. Opinions differ. Personally, I don't need to see a (former) railroad on the map, when the tracks are physically gone, especially if it's converted to a cycleway. If both should appear on the map, then probably 'historical tracks' that are no longer visible should not be mapped, or at least not this way. Currently, mapnik renders railway=disused/abandoned/construction all with the exact same style: a dotted line. Historical items then might be mapped in a different way that is usefull for, for instance, a separate rendering or different layer. That would not only be the case for historical railway tracks, but as well for historical city walls, canals, gates, old river quai and docks, ... that all have influenced city development. But that is another discussion. Hard to solve, unless *every* data user starts to understand and process something like date_start/date_end tags. Another 'historical' point is that it is a pitty that OSM doesn't offer a kind of 'time-machine'. On one side it would be nice to see the growth of OSM that way, on the other side the map we are currently making will be historical one day. If - for instance - Doel would be broken down for harbour expansion, going back in time then would show how it was before, same would be if the 'hedwigepolder' on the other side of the border would be flooded again. But again, that is just a side remark and another discussion. Don't forget the Prosperpolder, where works are already under way to open it to the Schelde. I fear the infrastructure needed to store, process and show OSM as it was in a particular point in time, is not easy to construct. The sheer data volume means you need quite some processing capacity, both in CPU and storage. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] data error? errors with osm2gml.xsl
For now I just remove this tag and process my data without it. For the Antwerpen status page I do not need it. Removing a tag just because a tool doesn't grok it, seems like the wrong thing to do. Unless you only removed it from your local data, of course, and not from the OSM db. There is nothing wrong with a tag named '3dshapes:ggmodelk' in OSM. The colon is used in various places in OSM tags, as a namespace delimiter. The tool needs to be fixed, not the data. By the way, I am the one that put it there. Be prepared for a lot more of these tags, near the NL border. See http://wiki.openstreetmap.org/wiki/3dShapes for more info. The /Details page also explains 3dshapes:ggmodelk, and what you can do with it if you encounter it. Basically, it's the value an object had in the original dataset. If you're sure that what's imported is right (for instance, really a house, really a forest, really water), there's no harm in deleting the key for that object. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Hi all
but I think the NGI won't even consider doing that. In the import It's certainly worth it to ask and explore this, before we turn all our attention to CLC2000. I also believe we should explore the Freedom of Information acts more. Especially the Federal Decree has some interesting sections on our being able to use official documentation released under FOI. But, being Dutch, if someone from Belgium could delve into this, that would be better, I think. One less barrier to scare the officials. :) section they describe how to do it. Do you all think it is worth it? I have the entire CLC2000 dataset on my server, and had a quick look. The answer is, obviously: yes and no. Con: The data is old, some things will simply be outdated. Pro: Some objects, like residential landuse areas, look pretty good. All the typically belgian 'linten' are very recognisable. Con: Other objects, like agricultural areas, are pretty large, and would certainly not form a single continuous area IRL. This would need extra checking after the import. Pro: landuse mapping in Belgium, outside where there is yahoo hires coverage and people have spent time tracing, is pretty lacking. Taking the specific things from CLC2000 that would work nicely would be a good step forward. Pro: the way the French have setup the Corine import is that you can exclude areas which are overlapping with existing OSM areas. You can then, later on, import those areas missed due to overlap, by hand, from a website. Ben said we could even delete existing OSM areas before the import starts, if we know the existing mapping is inaccurate. If you guys want, I could set up a map overlay with the raw CLC2000 data, so you can check it out? I have got some more plans, but I promise I want do any bulk uploads without consulting you ;-) Do you have any other potential datasets in mind? -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] De Lijn: gegevens vrij (onder voorwaarden)
Marc Coevoet wrote: Die letuffe server toont welke gemeenten volledig zijn/doneerden. De legende van de kleuren heb ik nu even aangevraagd. http://beta.letuffe.org/?zoom=7lat=46.17913lon=2.89885layers=BFFFT Linksonderin staat een link. http://wiki.openstreetmap.org/wiki/Yet_another_validation_tool_for_osm_data#admin_level.3D8 -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] De lijn: kaart met ballonnetjes, en de passerende bussen
On 12-4-2010 20:20, Marc Coevoet wrote: Iemand een idee?? Ik heb een idee: vraag De Lijn of we de data op bredere schaal mogen gebruiken dan de 'onderzoeks'-licentie op persoonlijke titel die je nu hebt verkregen. Import van de locaties van bushaltes in OSM vereist dat de licentie zich niet tegen commerciëel gebruik verzet. Vermits ze de hele dataset niet op die manier willen vrijgeven, willen ze wellicht wel alleen de haltelocaties vrijgeven tegen deze voorwaarden? -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] De lijn: kaart met ballonnetjes, en de passerende bussen
On 12-4-2010 22:55, Marc Coevoet wrote: Welwel, ik ga ervan uit dat als we gaan naar de chauffeurs, we gelijk krijgen. De chauffeurs hebben geen zeggenschap over deze bedrijfsvoering. Ik ga ervan uit, dat als we gaan naar Van Quickenborne, we gelijk krijgen. En dat is een heel andere piste. Praten met Van Quickenborne is prima, om meer informatie vrij te krijgen, maar zal voor de data van De Lijn, waar we het nu over hebben, nog niet uitmaken. Ik schrijf over deze franse licentie, opdat het hier ook eens zo zou worden ... We kunnen allicht hopen. Zolang er niet gelobbyd wordt voor deze zaak, zal er niet veel veranderen. Iemand, en dan heb ik het voor het gemak maar over een Belg ipv mezelf, zal zich in Brussel voor de zaak moeten gaan inzetten. Bijkomend probleem is dat er op zoveel niveaus gelobbyd moet worden. Bij de federale regering, de gewesten, de gemeenschappen, de gemeenten. De tweede piste die bewandeld moet worden, is het opvragen van informatie met gebruikmaking van de diverse decreten over Openbaarheid van Bestuur. Als we daar nuttige informatie uit kunnen verkrijgen, en we kunnen er interessante initiatieven mee ontwikkelen, helpt dit om bij de overheid aan te tonen dat het tevens in hun interesse is om meer informatie vrij te geven. Zeg Lennard, wat is jouw interesse in de Belgische situatie?? Wat heb jij tegen/voor het vrijkomen van Belgische gegevens?? Ik ben voor het vrijkomen van Belgische gegevens. Uiteraard. En mijn interesse is gedreven door het feit dat ik tevens werk aan OSM in België, vanwege de nabijheid. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Deinze: last call
One of my idea would be to do a detailed mapping of the foret de Soignes / Zonienwoud, and organize this with local associations that are interested in the promotion of the forest and education to ecologie. This could also be done in collaboration with scientists who could be interested in a better mapping of the forest for further analysis. Wht do you think about this ? I would not recommend mapping a forest, if you also want to cater for newcomers. Interpreting GPS tracks is hard enough when you just start, and working with GPS tracks from a forest with lots of tree cover requires experience to make the right decisions. However, if you have the right persons attending, and you are able to convey those caveats, it could be a fruitful day of mapping. If you do expect lots of newcomers, I would start with a residential area. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CORINE Land Cover 2000
On 16-5-2010 22:34, Renaud MICHEL wrote: Well, there's no harm in asking, but as you say it seems compatible with the actual CC-By-SA (but I have no idea for ODBL). I just learned the question went out, but we have not received an answer. That's not so strange, with Ascension Day and a weekend in between. It seems like a great idea, how does the import work? We have already some data imported in Belgium from the french import, will those regions need manual editing to integrate the two imports? Should we keep the landuse where they already exists in OSM belgium, or is the CORINE data much more accurate and should be preferred? The CORINE data is not that bad, but is slightly generalised in the sense that features smaller than 25 ha are not present, and are rolled up as part of a larger area. The way the import in France was done is to compare the CLC polygons to OSM polygons. Only CLC polygons with no overlap or a very small overlap to OSM polygons were automatically imported. The non-imported part of the dataset was then added to a web service, where each can select and export a non-imported polygon and add it to OSM themselves: http://clc.openstreetmap.fr/ -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CORINE Land Cover 2000
On 16-5-2010 22:35, Martijn van Exel wrote: I fail to see why there would be a problem, legally, to import CORINE if the license is compatible. IGN/NGI would not be a party in this, as the EEA licenses CORINE. The NGI/IGN reference is for the CLC 2006 dataset specifically. The 2006 dataset is not publicly available from the EEA and has to be obtained through the participating national agencies. We already received permission to use the CLC 2006 dataset in The Netherlands, but we then have to buy the actual dataset. The point is moot, since we already have the much more detailed 3dShapes data. We can still use CLC (2000) to enrich 3dShapes classifications. For Belgium, it's different, and any broad addition of land cover to OSM would mostly be welcomed, I assume. If it would be actually useful is another matter altogether. I think it would look nice on lower zoom levels, and could be useful as a starting point for individual mappers to improve upon, but more detailed data may already be available which would make a blanket import action undesirable. That's why we're not aiming for a blanket import, but a directed (but still national) import. See my previous reply about the import method and the comparison to existing OSM polygons. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CORINE Land Cover 2000
On 16-5-2010 21:47, Lennard wrote: The amount of changes between CLC 2000 and CLC 2006 is on the order of 0.5% over the entire covered region. The overwhelming amount of polygons would be unchanged. I think there's not much harm in working with CLC 2000, even if it is 10+ years old. To follow up this part, a list of project details, including a contact person and the changes between CLC 1990 and CLC 2000. If we extrapolate the amount of changes for the 2000-2006 update, we can see that overall the 2000 data would still be pretty valid. http://etc-lusi.eionet.europa.eu/CLC2000/countries/be/full -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CORINE Land Cover 2000
On 19-5-2010 7:01, Martijn van Exel wrote: can say is that he was not quite sure about the status of CORINE 2006 - as far as I can see it is included in http://www.eea.europa.eu/data-and-maps/data/corine-land-cover-2006-clc2006-100-m-version-12-2009 but I might not be quite sure what is being meant here. What you see there is a bitmapped version of CLC 2006, with 100 m resolution. There is also a 250 m version there, and bitmapped images of the changes going from 2000 to 2006. The seamless vector data, however, is not available, and that is the version we would need. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CORINE Land Cover 2000 (now with permission)
On 18-5-2010 2:04, Ben Laenen wrote: OSM just works like that: start with big things and then get more and more detailed. For 70% of the country Corine is better than existing data, and I welcome anything which is an improvement. There is now a blanket permission from the EEA to use any data available through the EEA website. This includes Corine Land Cover 2000 http://lists.openstreetmap.org/pipermail/imports/2010-June/000594.html http://wiki.openstreetmap.org/wiki/European_Environment_Agency I have the necessary databases set up and the relevant scripts from the French CLC import on my computer, and can work on generating a test import file. I could also generate an overlay showing the result of the import file, after filtering out CLC polygons that overlap with existing OSM polygons. Ben had the notion that perhaps we should, before the import, delete inaccurate polygons, especially in the Ardennes. The proposed overlays could assist in determining whether that is necessary, and if so, at which scale. Now that the legal issues have been resolved, and the technical setup has been mostly performed, the question remains about whether to proceed with an actual import? Don't worry about it happening overnight, we have plenty of time to discuss and review the steps involved. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] MapQuest Belgium
Today, MapQuest rolled out a Belgian version of their Open MapQuest program. This is based on OpenStreetMap data and also uses several tools that have come to be regarded as part and parcel of OSM: The mapnik renderer is used to create the map, and Nominatim is used as the search engine. You can also click on the symbols at the top of the page, to get popups on the map with the category you searched for. Currently it seems to be in French only, but I'm sure they've planned a Dutch language version in the future: http://open.mapquest.be/ -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Meer regeringsdata van UK (transport)
Een tijdje geleden gaf ik de link naar alle bushaltes in de UK, vrijgegeven data. En je hebt toen talk-gb gevonden. Voorstel om dit dan ook daar te plaatsen, of het moet een voorbeeld zijn van hoe een ander land wel data kan vrijgeven en België (cq. subdelen ervan) dat niet doen/kunnen. niet zo leesbaar als de gegevens die ik van de lijn kreeg (ze updaten de ftp server regelmatig, wil iemand es een nieuwe set?) Ik had verwacht dat die boodschap nu toch overgekomen zou zijn, maar: driewerf neen. Deze data van De Lijn is niet licentietechnisch niet bruikbaar voor OSM. Zie ook de berichten van vorige maand, waarin De Lijn stelt garanties te willen hebben, die wij niet kunnen bieden. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Simpele vragen van simpele mapper
On 20-11-2010 17:51, Karel Adams wrote: Leg me maar eens wat volgens u de GOEDE manier is om recht te zetten wat een of andere brave maar wellicht niet erg snuggere voorganger mismeesterd heeft in Balen. Ik heb het hier over de N136, vanaf het dorpscentrum noordwaarts. Zoals wel meer gebeurt verandert deze een paar keer van naam, maar in de huidige weergave is het Kerkstraat tot helemaal buiten het dorp. Ik zag totnogtoe geen andere oplossing dan deze erg lang Kerstraat verwijderen, en dan apart nieuwe straten aanmaken. Maar dat vond ik zelf ook wel belachelijk, zodat ik het voorlopig maar heb laten staan. Hoe dit wel aan te pakken? Cut the way in two at the position where the name changes, and then change the name of the part that isn't Kerkstraat anymore. Repeat at the next spot where the name changes. How to cut a way at the right spot, with Potlatch: Shift-click on the way to create a new node at the right spot, if there isn't a suitable node at that spot already. Then select that point and click 'x' to split it at that point. With JOSM: select the way, hit 'a', and shift-click at the right spot to insert a node. Select the node, and hit 'p' to split the way in 2. In Merkaartor: I have no clue, but maybe Chris Browet can comment? -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] University of Delaware
On 13-2-2011 14:19, Karel Adams wrote: Filip, met alle respect maar ik vind dat dit geen prioriteit mag zijn. Hoo schoon ik het allemaal ook vind, we moeten de essentie van het project respecteren, en dat heet nog steeds openSTREETmap. Al de rest mag er zeker bijkomen, er is daar niets verkeerds aan. Integendeel, het is met zulke zaken dat men een buitenstaander kan overtuigen dat OSM een meerwaarde kan hebben boven de commerciële aanbieders. Het doel van het OpenStreetMap project is om een *database* op te bouwen met vrij beschikbare geo-informatie. In het verleden ging dat inderdaad voornamelijk over straten, maar tegenwoordig moet dat toch breder gezien worden. Het is echter *geen* doel van OSM op zich om dit soort mooie implementaties te maken met die data. Dat is aan derde partijen. Zelfs de kaart die men standaard krijgt op openstreetmap.org is eigenlijk geen deel van het project, maar natuurlijk wel een mooi visitekaartje. Het draait dus om de data, niet om wat anderen daarmee kunnen maken. Maar ons eerste doel moet zijn om een compleet stratenplan van België te hebben en daar zijn we nog héél ver vandaan. Inderdaad, alhoewel het gezegd mag worden dat we sinds enige maanden wel veel sneller straten en vlakken kunnen toevoegen, door het tracen van Bing. Dat heb ik bijvoorbeeld zelf ook gedaan, door in rap tempo straten en plaatsen in mijn omgeving op de kaart te zetten. Daarmee mis je natuurlijk alle overige informatie 'on the ground', zoals namen, restricties etc. Dat is dan voor het komende voorjaar/zomer, om op basis van die ruwe, overgetrokken informatie, in hoger tempo de rest toe te voegen. Als de wegen zelf al in de database zitten, kun je een stuk rapper door een plaats heen om deze extra informatie te bekomen. Wat wellicht wel nuttig zou kunnen blijken is een kaart waar je snel concentraties van straten zonder naam kan herkennen. Op de noname kaart moet je te ver inzoomen om een mooi overzicht van het land te krijgen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cell Phones Antennas
On 21-4-2011 22:35, Pol wrote: Ok I will do it. I'll contact them tomorrow and ask them precisely. I'll do my report on that mailing as soon as I have a reply or an answer. Excellent! I hope they're more willing to cooporate than they were to you before. In general, we cannot use any government data in Belgium without explicit permission. Either to any user or to OSM specifically. Ok I wasn't aware of that. It also depends on which part of the government it is. For example: If they publish a law that documents coordinates, we can use it without questions. Any law, decree is fair game, but IANAL. But again, if I had spotted myself those antennas, the problem is still the same ? No. In that case, *you* gathered the data. You can add that to OSM without any issues. It's the same reason we cannot enter street names from other maps, but we can enter street names we mapped ourselves. Also noteworthy is that the map on ibpt.be http://ibpt.be says Door deze site te gebruiken zijn de gebruikers gebonden door de gebruiksvoorwaarden van Google. / En utilisant ce site, les utilisateurs sont tenus par les conditions d'utilisation de Google. So does it changes something ? It shows either of two things: 1) They just included that generic notice without thinking too much about it. 2) They had to include it to be able to show a Google map. Either way, the wording applies to the 'site'. So, please ask them to clarify their position with respect to their data. If they're willing to open up their data, doing it as a separate download, not on the map, is best. It avoids all traces of Google involvement. Also, if you gathered your list of antennas by going over every map popup and writing down the coordinates, you've created a derivative work from Google. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cell Phones Antennas
On 21-4-2011 23:31, Pol wrote: It's not my intention at all, by far !!! I'm a contributor and I want OSM to be the best map for everyone, everyday. We do too. That's why we're so cautious about data and licenses, and why I was so blunt to bring this import to light on this mailing list. Can't wait for tomorrow ! I'll call them and I hope that I'll have the good arguments in my mouth when I'll explain the situation and why we would like to have it on OSM (/which is the hardest part/). Let's hope so. You'll have to think about a reply to their previous argument of 'security'. What exactly is so dangerous about a list of telco towers? As you also said, anyone can create such a list. It only takes a lot of time. If someone wants to sabotage them, they certainly don't need to collect the locations for the entire country. They're also publishing their database on a Google based map. That's not exactly keeping it secret either. :) But, whatever happens, and I do understand why you wanted to import them into OSM, I hope we can talk about this before anyone does an import, next time. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Logboek gebied
Ziet er op zich goed uit, maar ik krijg steeds Data not visible at this zoom level, please zoom in to see stuff. Het is me in 50 pogingen geloof ik één keer gelukt daadwerkelijk in te zoomen. Het is behoorlijk irritant als je geadviseerd/verzocht wordt iets te doen wat je niet kunt doen... Hoe probeer je dan in te zoomen? Het werkt hetzelfde als op de osm.org kaart, bijvoorbeeld. Dubbelklikken, of het de scroll/zoom-elementen linksboven gebruiken, of met shift-dragging. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Logboek gebied
On 28-4-2011 0:49, filip wolters wrote: Ik heb OWL en ITO eens bekeken. Ofwel kan ik er niet mee werken ofwel vind ik het geen nuttig instrument om mijn ingevoerde data op te volgen. [...] Inderdaad, als je dat er van zou verwachten, dan is het een karige tool. Je kunt wel een RSS feed opzetten, zodat je direct een seintje krijgt als er in een gebied dat je interesse heeft, gewerkt is. Bij ITO kan je filteren op sessions, tags en users maar niet by me en by not me. Dat kan zeker wel. Nergens al je input met wijzigingen, zeker niet in een groter gebied over een langere tijd. Nochtans zou op je persoonlijke pagina bij wijzigingensets zoiets wel te maken moeten zijn door iemand met wat kennis. Ik denk dat ze een uitgewerkte patch met open armen tegemoet zien. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] OSM stats
On 14-5-2011 10:20, eMerzh wrote: Hi, the lenght of osm highway are directly calculated from an osm2pgsql with data from the 12th april. I assume you took the projection into account? Plainly doing ST_Length will sum the projected length of the roads. The real length will be much lower. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Importing csv, good practices and tips : Multipharma Case Study
On 19-5-2011 12:01, Julien Fastré wrote: @Lennard : i didn't know about this test API. Can we use the test api with JOSM ? Yes, change the api url in the config. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Workshop Trage Wegen
On 9-6-2011 21:40, Wouter Hamelinck wrote: * First of all, please try to avoid mapping in the Haaltert region the until that day. Now there remains a lot to be done (it is just out of the old good quality Google image area). For newcomers it is more fun if their work shows clearly on the map. I seriously hope you actually meant just out of the old good quality BING image area ? * If I remember well OSM-be has some loggers available for mapping parties and the like. I could not find a page on the wiki about it. Anyone has information? If they are available and could be used for the workshop, how can I get them. I am commuting between Ghent and Brussels so I can easily pick them up in any those two cities. http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GPS_Devices -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Problems with JOSM's unwanted behaviour.
But If you click on the last node of your way, then press Alt while adding the next node, then you end up with a new way that share its first node with the previous way. Exactly, and that was what he was told in the ticket. I entirely disagree with the suggestion to disable autocontinuation, and am very content with the way JOSM currently works in that respect. The example in the ticket (starting from a node in the middle of a way produces a continuation) is convoluted as well. It *doesn't* do a continuation of that way. That's also impossible in the data model. In the example (in the ticket) that node is also the endpoint of *another* way, and it does do a contination of *that*. However, it's made out to appear that selecting a non-endpoint node of a way and then drawing from that will produce a continuation. Not so. In short: use the modifier key when drawing a new way from an existing endpoint node. Don't go through all the hoopla of extending a way, then splitting it, deleting the tags, applying new tags. That only makes life difficult and indeed obfuscates the way history. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Problems with JOSM's unwanted behaviour.
In the example (in the ticket) that node is also the endpoint of *another* way, and it does do a contination of *that*. However, it's made out to appear that selecting a non-endpoint node of a way and then drawing from that will produce a continuation. Not so. No, you didn't understand the examples. I never sayed that a road was boken up in the middle and then continued. It is just when you start a I was not saying that either. [...] This is exactly what happens when editing at node 803205990. This is exactly what I described. As most often, you intend to add a new road, the default behaviour should be like that. I think it comes down to being of another mindset. For me, clicking an end node to continue that way seems the natural thing to do. If it so happens that end node is part of a crossing, so be it. I have to remember to use ALT if I want to start a new way at the crossing. Of course, I could be entirely spoilt from having worked this way in JOSM for years. I thought Potlatch did the exact same thing. What is the handling in Merkaartor for this situation? (Count once your ways when editing and compare extended existing versus added new ways) That's not a fair comparison. Often enough when adding new ways, you are *not* at a junction with another way endpoint. You might be starting a new way in the middle of nowhere, or branching off of another way, but *not* at a junction. In my experience, when adding new ways, starting one at an 'endpoint junction' is the exception. The splitting and additional obfuscating happens, while this seems the obvious way for most users of getting out of this unexpected alongation. For some messy results see my examples Verstrekenstraat and Jachtdreef. I can actually agree with your other point, being that when splitting a way, the existing ID should stay with the longest fragment. You might modify your JOSM ticket to emphasize that part, or perhaps even better: start a new ticket with just that request (with a reference to the current ticket). -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppuntennetwerk/Cycle node network
That is OK for JOSM, but a list like this (at the bottom) is simply not meaningful. http://www.openstreetmap.org/browse/changeset/917?relation_page=3 This is much clearer. Then ask for that page to display a note=* tag when a name=* is absent, like JOSM does. But why would you start making collection relations when a scheme already exists? See here: http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging Which as far as I can see meets your needs and relations conforming to that scheme have been in the database for over a year. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] rendle
On 11-1-2012 19:33, Sander Deryckere wrote: Met de nieuwe CT geef je als mapper idd alle rechten aan de OSMF. Het heeft dus niets met de licentie op zich te maken maar wel met de CT. Je geeft de rechten niet aan de OSMF. Je verleent de OSMF een eeuwigdurende, niet herroepbare, etc., _licentie_ op jouw data. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Snelheidslimieten
On 13-2-2012 9:57, Sander Deryckere wrote: Je kan ook even op de maxspeed kaart kijken om te checken welke wegen een maxspeed tag gekregen hebben, en welke die zouden moeten krijgen (als de maxspeed niet af te leiden is uit de omgeving dmv algoritmes). http://www.itoworld.com/product/data/ito_map/main?view=124 (deze kaart vraagt wel wat tijd om te laden). Als dat te langzaam is, is er ook nog http://maxspeed.openstreetmap.nl/ (Hoewel ook die weleens langzaam kan zijn :)) -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Missing Maxspeed in Brussels
On 6-8-2012 20:18, Joren DC wrote: I made some big changes in my area yesterday (14:00); According to the wiki it will update every day at 17:00 for the past day. No changes seen so far. I'll wait a bit longer, because this map is very useful in order to keep an overview of the missing speed limits. I'm experimenting with JOSM and trying to make a 'speed limit'-layer if possible. Of course, having maxspeed displayed in JOSM isn't very hard, and done before: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Maxspeed_tagging Also, for the Benelux, we have our own maxspeed overlay, which is updated continually: http://maxspeed.openstreetmap.nl/ http://maxspeed.openstreetmap.nl/?zoom=12lat=50.8562lon=4.38844layers=B -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland, bedankt Jo
On 23-8-2012 15:22, Jan-willem De Bleser wrote: - Verkeerde nummers, zoals relation bicycle rcn -60 die op node 75 eindigt, komen voor omdat de code niet op de juiste manier het eindpunt van de relation bepaalt, maar eerder gokt. Ik heb een voorstel gedaan voor een wijziging in de code dat dit hopelijk zal oplossen. Nu zijn we alweer bezig om deze kwestie voor 1 specifieke editor proberen op te lossen, terwijl een simpelere en meer pragmatische oplossing al jaren in gebruik is: het tonen van een door de mappers zorgvuldig ingevulde note tag. Gaan we nu voor elke editor verzoeken indienen om deze 'name' te ontdekken in de data en te tonen? Want als Potlatch deze manier zonder fouten doet, zullen Potlatch-mappers geen note meer zetten. Consequentie zal dan zijn dat er toch scripts moeten blijven draaien die de note invullen. Naast de editor toont de webinterface van OSM ook niet deze synthetische naam. Terwijl ook daar het tonen van een notitieveld bij afwezigheid van naam en referentie ook de kortste, simpelste en meest pragmatische oplossing is. Het is mij verder om het even welke methode gekozen wordt, als het maar voor elke gebruiker van de data op eenzelfde manier zichtbaar is. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland, bedankt Jo
On 23-8-2012 21:56, Jan-willem De Bleser wrote: Maar de note tag hoort toch niet getoond te worden? Daar heebben de Potlatch2 devs gelijk in, dat note bedoeld is voor de surveyor en niet de kaartgebruiker. En wie gebruikt de editors? En wie niet? ... Juist: surveyors/mappers resp. kaartgebruikers. Die laatste categorie kijkt naar de gerenderde kaarten. Deze tonen de note toch al niet. Je vraagt nu dat note anders wordt behandelt voor Benelux dan voor de rest van de wereld. Daarbovenop is de note zoals die nu ingevuld wordt redundante informatie, en als we de softwaremakers zover krijgen dat ze die niet meer nodig hebben, des te beter. Je moet *alle* softwaremakers zover krijgen dat ze code ontwikkelen om uit de data deze synthetische naam te destilleren. Dat is me nogal een vraag. Het meest pragmatische oplossing is een naam verzinnen voor die routes, want dat wordt al getoond. Het meest pragmatische oplossing is echter niet noodzakelijk de juiste. Daarmee wordt die naam dan ook getoond in kaarten. Is dat dan gewenst? Ik denk dat we niet zomaar uit zullen geraken. Deze discussie zal nog regelmatig terug kunnen komen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 28-8-2012 21:06, Jo wrote: Als ik zo'n paaltje tegenkom en ik volg 1 route, dan zou ik graag ook het begin van die andere routes ingeven, maar ik weet dan niet waar het paaltje aan de andere kant staat. Welk nummer erop hoort te staan, weet ik natuurlijk wel en dat kan ik dus al in de note tag vermelden. Dit is exact de reden waarom ik voorstander ben van het (ook) gebruiken van de note tag. Bij het mappen van zo'n netwerk moet je op een knooppunt toch altijd kiezen voor 1 van de routes, maar de andere kun je alvast als beginnetje aanmaken in OSM, met de note tag als hint. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:14, Ivo De Broeck wrote: Erg is dat, in Potlach zijn ze gewoon correct. En nu Potlach moet de note NIET tonen. Wanneer gaat het eindelijk doordringen dat er internationale afspraken zijn. Potlach is bij mijn weten de enige die deze normen 100% invult. De hiking ipv foot is daar een mooi voorbeeld. Blijkbaar had men nog niet opgemerkt dat 'foot overal in het rood werd weergeven in de wiki en Potlach ongevraagd hiking invult. Tja Tag-verschuivingen zijn in het verleden ook vaak via attritie gegaan, totdat het de moeite loonde om de laatste paar % dan maar in 1x om te zetten. In de wiki zetten dat een tag verouderd is, is echt niet genoeg om het ook zo te laten zijn. De data is leidend, niet de wiki. Verder is er geen mechanisme om mappers van de oude tag in te lichten over elke verandering. Soms ontdekt men dan bij toeval dat iemand ooit in de wiki eens iets heeft neergezet en dat een editor met wat basisinstellingen een andere tag gebruikt voor zoiets als een wandelroute. Tip: Potlatch heeft naast de presets ook prima mogelijkheid om tags naar eigen keuze in te vullen. Zo kun je dus ook met Potlatch route=foot invullen. Je bent niet afhankelijk van wat Potlatch voorschotelt. JOSM is een prachtige tool voor mensen die weten waar ze mee bezig zijn. Potlach is de ENIGE tool voor mappers (kijk bv eens bij building, de gebruikers kan onmiddellijk de juiste soort building kiezen zonder nonsens in te vullen of vijf avonden te studeren om te proberen de wiki (vooral de Belgische) te ontcijferen. building=yes Voila, klaar. Vraag: zijn we nog goed bezig? Dat mag ieder voor zich beantwoorden. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:37, Jan-willem De Bleser wrote: Ge brengt me wel op een gedacht: we hoeven het niet te sorteren, alleen de eindpunten te detecteren. Stel dat je alle wegen doorloopt van de relation en telkens hun eindpunt toevoegt aan een lijst. Deze Je legt met deze methode ook wel meer load op de API. Die is al niet zo vlotjes op complexe relaties met veel revisies. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:43, Jo wrote: Lol, zal ik ze er overal terug inzetten dan? 't Is eigenlijk een kleinigheid. En daarna ga je dan de note tag afschaffen, want redundant? Zo gauw je JOSM en Merkaartor en welke editors hebben we nog meer hebt aangepast zodat die ook de eindpunten zelf vinden. :P Hoe kan een notitieveld van 1 mapper aan de anderen nu ooit redundant zijn? -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:46, Jan-willem De Bleser wrote: Je legt met deze methode ook wel meer load op de API. Die is al niet zo vlotjes op complexe relaties met veel revisies. Sorry, ik volg even niet. Er werd gesproken over het bijkomend inladen van ways om maar de eindpunten te kunnen vinden. Dit in het geval niet de volledige lijst met leden was ingeladen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voertuigklassen
On 10-10-2012 21:37, Ben Laenen wrote: Case in point: I still have to find the first road in Belgium tagged with access=destination that explicitely adds bicycle=yes and horse=yes (oh yes, http://www.openstreetmap.org/browse/way/26740921 You're welcome. :) I did that for a while, back then. Then it got tedious and I always forget horse=yes these days. except a road where I added it myself because it had an extra uitgezonderd fietsers sign below the uitgezonderd plaatstelijk verkeer. That extra sign is quite unneccesary. 2.47. De opschriften uitgezonderd plaatselijk verkeer of plaatselijke bediening duiden op een openbare weg die slechts toegankelijk is voor de voertuigen van de bewoners van die straat en van hun bezoekers, de voertuigen voor levering inbegrepen; ook voertuigen voor onderhoud en toezicht, wanneer de aard van hun opdracht dit rechtvaardigt, de prioritaire voertuigen bedoeld in artikel 37 en fietsers en ruiters, hebben er zonder uitzondering toegang. 2.47. Les termes excepté circulation locale ou desserte locale désignent une voie publique qui n'est accessible qu'aux véhicules des riverains de cette rue et des personnes se rendant ou venant de chez l'un d'eux y compris les véhicules de livraison; y sont aussi admis sans exceptions les véhicules des services d'entretien et de surveillance, lorsque la nature de leur mission le justifie, les véhicules prioritaires visés à l'article 37 et les cyclistes et les cavaliers. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Initial stuck to the name
On 11-1-2013 20:43, Ben Laenen wrote: Zoals hierboven gezegd: notulen van de gemeenteraad. Dat zal natuurlijk moeilijk op te zoeken zijn voor de meeste straten, maar je kan bijvoorbeeld eens vragen of ze een officiële straatnamenlijst willen ter beschikking stellen. Nog een verlate reactie, maar Ben heeft gelijk. En met wat Google-kennis (het gebruik van site:* ) kun je al heel gericht zoeken zonder al over een officiële straatnamenlijst te beschikken. We weten dus dat er een L. Claeslaan bestaat. Echter, een gemeente werd niet genoemd. Zoeken op osm.org levert 1 hit: Zoutleeuw. http://osm.org/go/0EqYH_5K Zoek dan eens met Google op claeslaan site:zoutleeuw.be. Et voila: Veel hits met Louis Claeslaan. Als je zoekt op l. claeslaan site:zoutleeuw.be kom je ook hits tegen waarbij deze weg in 1 adem genoemd wordt met de Elstraat en Dungelstraat. We kunnen er dus nu gevoeglijk wel vanuit gaan dat L. staat voor Louis. Weer een afkorting in OSM weggewerkt. Aan Guy de eer om deze in te voeren. :) -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Gebruik layer=-1 voor landuse
On 16-10-2013 8:52, Georges De Gruyter wrote: Het antwoord is gekomen, heb nog op de ongerijmdheid gewezen van zijn vergelijking met tunnel en brug en gevraagd om de discussie verder via de mailing list te voeren : In Nederland is elke landuse=residential met layer=-1 getagt. Dat lijkt me ook logisch want als je bijvoorbeeld een landuse=cemetary of garages of zo hebt, dan wil je niet dat die onder de residential gerendered wordt. Die anderen zijn belangrijker dan de residential. En de residential onderbreken of een gat maken voor de andere landuses is compleet onnodig en zorgt voor veel overbodige data. Ik zie dat niet anders dan een layer toevoegen aan een tunnel of een brug. Daar wil je ook taggen voor de renderer zodat die goed rendert. Een grote landuse is veel overzichtelijker en handiger om mee te werken, in alle opzichten. In Nederland zijn de gebieden met landuse=residential al in een heel vroeg stadium geïmporteerd, in de tijd van de AND-import. Toen was het blijkbaar nodig, of de toenmalige renderers (bijv. osmarender) ondersteunden het niet, om met de hand de landuse te ordenen. Osmarender sorteerde bijvoorbeeld alles per layer en renderde dan de objecten in volgorde waarin ze in de .osm file stonden, dus met oplopende ID's. De huidige methodiek van renderers, in ieder geval die ik ken en gebaseerd zijn op mapnik en/of de standaard kaart op OSM.org, is om te sorteren van grootste oppervlakte naar kleinste (binnen een layer klasse). Als je het in die volgorde rendert, zal het grootste gebied (een bebouwde kom met landuse=residential) altijd onder kleinere gebieden (een grasveld, een kerkhof) komen. Het argument van layer=-1 voor landuse=residential heeft dus zijn oorsprong in het verre verleden. Met de huidige generatie renderers (en manieren om met data om te gaan) is het m.i. niet relevant meer. In NL had de uit de AND-tijd overblijvende landuse=residential allang ontdaan kunnen zijn van layer=-1. Als dat gedaan is, is er alleen indien de landuse=residential valt binnen een nóg groter vlak landuse (bijv. een bos) nog maar een probleem. Echter, daar hebben we tegenwoordig multipolygon's voor, waardoor we een gat kunnen maken in het grotere vlak. En ten slotte, we zouden ook weer kunnen terugkeren op een hele oude discussie, die van landuse als fysieke eigenschap vs. landuse als functie-omschrijving. Het is jammer dat dit in de begindagen niet direct onderscheidend is gemaakt in de tagging. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] cycle/footpath
Robin Paulson wrote: while we're on the subject of convoluted tagging schemes for highways, i've always been intrigued by the following combinations, which seem to mean the same thing, but are clearly different: highway=footway cycle=yes highway=cycleway foot=yes is there any difference between these two? Yes, in the cases where I've used this way of tagging. The difference is in the signs used. The highway=footway;cycle=yes is mainly a footway and marked as such, but with a sub-sign saying 'cycling allowed'. This implies that the main users are pedestrians, and cyclists should take all due consideration to them, like not claiming the road. Cyclists are 'guests'. The other is actually the other way around. It's marked with a cyclists sign. You are allowed to walk on it (since there might not be a suitable footpath or sidewalk/pavement nearby), but have to realise there are (fast) cyclists around. Often, the foot=yes is implicit, because pedestrians can go pretty much anywhere, like on cycleways if no pavement is present or even the main road if neither is present (at least in The Netherlands and Belgium). I'm using an explicit foot=yes if the cycleway is not paired with a nearby pavement/footway, so the routers will know they can use it for pedestrians. Now, what I'm curious about, and what came up in recent discussions on talk-be and #osm-nl, is how far the implicit foot=yes goes in both OSM in general, and current routers specifically. Not every country has the same implicit access rules. For instance, in Belgium where a do-not-enter-for-drivers sign (round, white with red border) is used, with a sub-sign 'residents only', it is implicitly assumed that foot=yes (since pedestrians are not drivers, the sign does not apply to them), but also bicycle=yes;horse=yes, even though they're legally both drivers, and don't have to live on that street. Currently, I would need to tag every such destination-only road in Belgium with: access=destination;foot=yes;bicycle=yes;horse=yes. Would it be possible in the future to mark such implicit nation-wide access=* rules for various types of road? So within Belgium, I could get away with the much easier access=destination and be done with it, unless there are explicit *=no access classes) ? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Live Data - all new Data in OSM
Matt Amos wrote: these might be of interest: http://matt.sandbox.cloudmade.com/ Which would have been fine and dandy in the past, but somebody needs to nudge that one into life again, /me thinks. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
marcus.wolsc...@googlemail.com wrote: Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. That's ridiculous. It's very possible for a bridge/tunnel to *cross* a zone, while not being part of the zone itself. E.g. an elevated motorway going over some ground-level zone, just isn't part of that zone. Even if that bridged/tunneled road had an exit into the zone, zonal regulations would only start (or end, for that matter) at that point. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Corine Land Cover becomes a potential OSM data source...
Martijn van Exel wrote: Interesting. We will be having the same kind of import versus existing data issue once more (if and) when the Nationaal Wegenbestand (National road database) is made available by the transport ministry. I did not give it much thought yet - may be some of my Dutch co-OSM-ers will have a more elaborate train of thought - but I was thinking along similar lines: import the data but tag it so that it won't show up in the map. Have a dedicated map layer on a local server that can be used to check existing user data, may be even a Potlatch layer if at all possible. I guess JOSM support would be easy enough through the WMS plugin. I have to agree with Frederik on this. With the NWB you mention, it's likely the vast majority of it will not be relevant to NL coverage, since we already have had a mass import of AND data. Why should we 'pollute' the OSM db with data that's not going to be used on a large scale. I'd too rather see such a source of data on a separate layer/db, through WMS for instance, so that we can compare, and (like Gervase puts it) merge down what we want. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] zones for motorway/in town/outof town?
Radomir Cernoch wrote: The idea is not to create a node here starts city and a node here ends the city. The idea is to create a polygon which defines the border of 50 km/h speed limit. The problem of forgotten end node, which causes cities to leak all over the planet, does not apply. Now we have an urban area, with a circular road with maxspeed=50, and streets and cul-de-sacs left and right of that road with maxspeed=30 zones. And that is just a simple example. The polygons are going to be complex in some cases. The problem now is that you cant actually work with polygons as for example a motorway could pass over a zone-30. Sorry, I maybe didn't make myself clear. Polygon rules do not apply for motorways. Is there any country, where a highway inside a city has different speed limit from the highway outside of the city? Even if yes, Yes. this can be specified in the set of country-specific rules... Don't focus on the highway-in-city bit. Focus on the $random_road_type with a different maxspeed bridges over (or tunnels under) a zone with another maxspeed bit. You'll have two zone polygons overlaying each other. I can imagine a situation, where a normal 50 km/h road goes through the middle of a zone-30. Then there are two options: 1) You split the zone-30 polygon into 2 polygons. 2) You tag the 50 km/h road with maxspeed=50. Right, exactly the scenario I mentioned at the top of this msg. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] zones for motorway/in town/outof town?
Radomir Cernoch wrote: Don't focus on the highway-in-city bit. Focus on the $random_road_type with a different maxspeed bridges over (or tunnels under) a zone with another maxspeed bit. You'll have two zone polygons overlaying each other. No, 'maxspeed' tag on a road does not imply a polygon with zone! There can be both in one place. Tag 'maxspeed' on a road is dominant and overrides any zonal restriction. And what if the crossing way in the above example is part of another zone? Don't say it can never happen. City planners are loopy. However it's important to notice that two polygons can never overlap (unless there is a futuristic city with zone-30 area flying in the air above a 130 km/h highway). Oh please, this is getting silly. I know it's pain to work with them, but the solution is to learn JOSM to split map into layers, not to adjust the data-model. Right. Even smarter editors. PS: There are more editors than JOSM. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] zones for motorway/in town/outof town?
Cartinus wrote: AFAIK a way with maxspeed=signals is used for those portals with the electronic speed signs you see over the motorway. I actually hope mappers only use maxspeed=signals for those motorway sections where the speed routinely changes based on congestion or time of day. Not to note the fact whether those portals are just merely present. And also not for the dutch system where portals signal a decreasing lower speed, just to alert arriving traffic that traffic in front of them is slowing down. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline error checker broken
On Sun, 2009-05-24 at 16:33 +0100, David Groom wrote: The coastline error checker ( http://tile.openstreetmap.nl/coastlines.html ) seems to be showing a server error. Any idea why / when this might be fixed? Try http://dev.openstreetmap.nl/coastlines.html But even though you may have the coastline slippy map at this location, it's dataset also hasn't been updating: http://hypercube.telascience.org/~kleptog/last_update.txt Last update of coastline errors: Thu May 14 15:00:14 UTC 2009 Using data available at: 090514 The tile name was moved to a new server, and a message was later sent to the maintainer of the coastline checker to... well... check it. The actual checker seems to run on hypercube. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is Xapi working?
Maarten Deen wrote: The server running the xapi service is down at the moment. Any info on what the problem is and when it's going to be resolved? And what is the status of the other two XAPI servers? Bearstech seems to be perpetually testing, and xapi.openstreetmap still serves 0.5 data and 0.6 service will start shortly (ever since the move to 0.6). Any help needed? Is XAPI 'officially' supported? I mean: is it considered one of the fundamental things in OSM land? I've had the telascience server serve me proper 0.6 data, so if there is a data issue, it's something that popped up at least after june 1st (that's the last time I can confirm getting data). There's more stuff on hypercube that's not running. The coastline checker is one of the major ones. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline
Ulf Mehlig wrote: http://dev.openstreetmap.nl/coastlines.html?zoom=9lat=-1.59059lon=-45.26367layers=B00T shows a blank map to me. Well, since the hypercube server is well and truly kaput at the moment, that is to be expected. The coastline checker runs on hypercube, and the slippy map above loads tiles from hypercube. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] full history of a way?
Richard Fairhurst wrote: Only if you save it. If you use the edit with save mode and don't save, you can just look. What I've always thought could be useful is that when you select an earlier version from the popup, it would show on the map as well. Often there's multiple previous edits, and you're not always sure which is the one you want to go back to. You could visually check a few, before you decide to go which one to revert to. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proper use of layer tag with the Mapnik renderer?
Jon Burgess wrote: Layer name=bridges status=on srs=... [snip] These rules will draw the motorway bridges above any secondary bridges regardless of the layering. I don't understand the logic behind the current rules, I believe they were done like this to fix some layering issues in some other complex junctions. And this is one of the subjects I want to tackle, besides speed optimizations. But the layering and z_ordering in osm.xml is already complex as it, and breaks down in some places, where you least expect it. The major problem is the different layers and styles in the stylesheet have no knowledge of each other's existence, and z_ordering is done per mapnik Layer. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Flood in Vienna
Bernhard zwischenbrugger wrote: Any idea where the blue background comes from in mapnik? It's usually caused by a problem with one of the coastline shapefiles. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Converting polygon to OSM way?
si...@mungewell.org wrote: Is there a way to convert the same polygon in to an OSM way so that I can merge this in and render it as a bounding shape (rather than the default rectangle). I have used osm2poly.pl in the past: http://trac.openstreetmap.org/browser/applications/utils/osm-extract/polygons -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal 'man_made:tower' and 'communications_transpoder'
John Smith wrote: Jokes aside that isn't actually far fetched since the ACMA (Australian Communications and Media Authority) has a big database of this information available, although I'm not sure of the license on the data and I don't really want to be the one responsible for importing it either for that matter. Indeed, it isn't far fetched at all. There has already been an import of tower locations in The Netherlands, both broadcast and GSM/UMTS. The official registry is here: http://www.antenneregister.nl/www/tpl/frameset.html The interesting part is that they also have public field strength tests, radiated power, directional coverage, frequency band. At the moment, they have been imported in a way that will not render: height=46 source=Antennebureau source_ref=http://www.antenneregister.nl/ technology=GSM 900 Examples: http://www.openstreetmap.org/browse/node/277227846 (this is a mast) http://www.openstreetmap.org/browse/node/277227844 (church tower) If the current proposal takes off, it wouldn't be that hard to do a re-import or re-tag them. The important bit is this, not all of these will be free standing GSM type base stations, some will be base stations installed on buildings/power poles, others are installed on water towers. Now that I think about the specifics of GSM antenna installations, it just re-enforces my thoughts that this should really be man_made=tower, tower:type= ... The hard part in the NL import will be determining whether it's an actual tower/mast, or on the roof of a building. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Circular relation by user mapper_07
Shaun McDonald wrote: This user, in changeset 1728656, has added relation 20773 has a member of itself. Is this allowed, and if yes, what does it mean, or is it an error? Yes you can do it, though I don't have a good reason for doing such a thing. I once did that by accident, but the API wouldn't grok it: http://trac.openstreetmap.org/ticket/2023 How did that user succeed to upload? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Just a thought
Marc Coevoet wrote: The *-ish give the maps of their country for free to OSM. Did you take your meds today? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] i18n-rich areas on the map
Shaun McDonald wrote: Yeah it would be neat to render a captionless layer in mapnik and then overlay text on it. Can mapnik support that? I'd have thought adding any sort of text to the map might have implications for the rendering itself. The problem is being able to do the text collision avoidance stuff against non-text features, hence why it's not been done before. Collision avoidance across layers is slightly doable, but requires a good amount of effort. This particular example isn't helped by the fact that you're dealing with variable length texts for the same feature here. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxspeed tagging Was: Best-practice-idea traffic_sign
2009/7/30 John Smith delta_foxt...@yahoo.com: bikes have the same speed limits here as every other thing on wheels, and even horses for that matter, and you can get tickets like all the other wheeled vehicles and even get done for drink driving on horses and ride on lawn mowers. That's exactly why I talked about my jurisdiction (The Netherlands), which doesn't have an implicit maxspeed for bicycles. It apparently never was a real problem in law enforcement, or it would've likely been amended. explicit speedlimits here as well, but Lennard was writing about implicit speedlimits (in town=50 and the like). Those are not valid for bicycles, but this is IMHO also not a very important issue, as most bikers don't get beyond 50km/h. Exactly, it's a moot point, and I included it mostly to make the point that there are so many subtle ways to handle maxspeed, that it would be difficult to make an all-encompassing tagging scheme. At some point, you'll just have to go with a generalized solution. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxspeed tagging Was: Best-practice-idea traffic_sign
Lennard wrote: The general solution is maxspeed is the highest of the maxspeeds of all classes of vehicle on that road. See also the signs we have in continental europe when you enter a country: there is usually a large sign specifying the maximum speeds on different roads (within town, outside town, motorway). I have never seen a different sign for mopeds, HGV's or vehicles with a caravan, it is always the maximum for all vehicles. In that case, your 100/100/40 example is easily collapsed into maxspeed=100. Let's see ... Hey, that's the current tagging scheme, already! Why did we need a change? :-) -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help Deleting Changeset
Ian Dees wrote: I downloaded the osmChange file from [1], changed all the create to delete and tried to upload it with JOSM. JOSM says there's no data to upload. I would think you'd have to open a new changeset and upload the osmChange directly to the API, not from JOSM. PS: Why did you tag all those nodes with landuse=cemetery? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help Deleting Changeset
Ian Dees wrote: How would I go about doing that? I suppose I could use curl or something similar, but is there a better way? If you can run perl scripts, have a look at: http://trac.openstreetmap.org/browser/applications/utils/revert -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cyclelane on left/right
Richard Mann wrote: The rendering can apparently be done using Mapnik's LinePatternSymbolizer (which does at least now have some documentation on the Mapnik site), but knowing that much and achieving the result are two different things. I'm hoping it's months rather than years. Very good progress has been made recently on offset rendering for the LineSymbolizer. I'm indeed hoping we can use this something this year. http://trac.mapnik.org/ticket/180 -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announcemen: Multilingual Country-List
Peter Körner wrote: It reaches 100% when /Tromelin Island /is set to not-ok. I got Bahasa Indonesia at 229/230 with 2 countries (Tromelin, Turkey) as not ok. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] server not rendering fully
Kenneth Gonsalves wrote: I am setting up an India specific server with mod_tile and mapnik. I finally got the beast to work, but at higher zoom levels it is not rendering completely. Apparently it is giving up instead of generating the tiles fully. Obviously there is some setting I have to make in apache config to force it to produce the full tiles regardless of how long it takes. I have disable cache and also lengthened the timeouts. Any one has a clue as what can be done to force it to render the tiles properly? The server is here: - Update your osm2pgsql to the current version (SVN version 0.66-17102) - Use the default.style from that newest osm2pgsql (SVN) - If you didn't already, pick up the newest osm.xml from SVN - Reimport your data into postgis - Update your mapnik to be at least 0.6.0 (current: 0.6.1) - Recompile mod_tile to synch it with the new mapnik - Clear your cache, restart apache - Try again To all that interests this: don't rely on tools included by your linux distribution to be up to date. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GSoC End: signFinder
Arlindo Pereira wrote: Perhaps would be a good idea to set up a wiki page for the signs with the colors and a sample photo? Not to mention the habit of some municipalities here to clarify the name of the street on a separate line. Or what about Belgian bilingual signs, with a creative Rue actual name Straat system, cleverly making use of the fact that in French the 'street' word goes at the beginning and in Dutch it goes at the end. building numbers of the block and the street's postcode (which are not like zip codes, they're different for every single street). ZIP code systems are not always of the one number for a big block of houses/streets variety. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Max recommended size for multipolygon relation?
John Smith wrote: Apparently there is a 1000 member per relation limit. Not true. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Stream in a tunnel
Andrew Ayre wrote: This way: http://www.openstreetmap.org/browse/way/39456905 is marked as layer = -1, tunnel = yes, waterway = stream. I was expecting it to be rendered by Mapnik as a dashed line and paler to indicate it was underground, but I don't see that. Any ideas why? Yes. It was rendered as a tunnel, but then overwritten by the non-tunnel variant. I've committed a fix, which will probably show up on the map in a few days. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] my flag is not showing on the green
Kenneth Gonsalves wrote: Parameter name=tableselect node from planet_osm_point where golf='green' as golfmarkers/Parameter but the flag is not showing. What could be wrong? select way from planet_osm_point -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] source=(survey, yahoo, gps...)
Valent Turkovic wrote: I can see that Potlach support source tag but JOSM doesn't. Do you use source tag? Why and how, please explain? I read the wiki page but I don't see many people use it and I'm wondering why. JOSM supports addition of any tag, provided you can type, so I don't see why you'd say it doesn't support source=*. You're not always, every time, relying only on built in presets, are you? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] source=(survey, yahoo, gps...)
Valent Turkovic wrote: Presets speedup many things, so it would be nice to have also presets for source= tag. Then create your own presets for your desired source=* tags. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] how to map this? cycleway or footpath?
Shaun McDonald wrote: This isn't a highway=path since the surface is tarmac. highway=path + surface=tarmac Plenty of =1 meter wide paths around that have concrete/tarmac/asphalt surfaces, for instance. From all the discussion in the past year, or at least since the invention of =designated, it seems we all just agree to disagree. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik rendering
Shaun McDonald wrote: It's really old news, that tile.openstreetmap.org is using the minutely diffs. But Steve was out at a conference when we switched over to the new tile server. Which is fast enough that it doesn't drop any render requests any more. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Revert changeset
Arlindo Pereira wrote: I'd like to ask to revert the changeset 2452658: http://www.openstreetmap.org/browse/changeset/2452658 It has been made by a user mistakingly adding Rio de Janeiro's POIs somewhere on UK. Done, but seeing as this was node/way creation, it could've just as easily been done by you or him by just deleting those objects. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
John Smith wrote: While my patch works, I don't know if this is the best solution to the problem or not: http://trac.openstreetmap.org/attachment/ticket/1666/osm.xml-patch I commented on the ticket. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
John Smith wrote: I didn't think it would be the best option, for most of the reasons you point out, however we have to start some where, so I thought I'd get the ball rolling. You're most welcome to do that, as in #osm-nl we have talked about regionalised rendering as well, in the past. I've rolled one small aspect of this out on our walking routes map, which renders different shields for The Netherlands and Belgium. I did copy our country boundary polygons to another table, because if for some reason the country boundary in OSM is non-closed, the whole regionalised rendering would fall over. My thoughts are that the import process should sort out the hard part of this: comparing of features against a polygon, and stamping them with a field we can filter on in mapnik. Either by running some sql at the end of the import (but should also work for diffs and changed polygons), or by doing this itself. What were the other issues you had thought up? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
John Smith wrote: This is already dealt with for coast lines, so it shouldn't be much of a jump to deal with country borders in a similar way. Indeed, but a factor to take into account. Only update your internal version of the boundary when a newer and valid version is in OSM. At present we're using multiple relations where the name changes along a route but the ref stays the same and vice versa so it's not possible with the current pre-processing that is done to do a nice little query to get the shield and name from the same query. I have no idea how to fix this. If those relations get flattened into a planet_osm_line geometry, you have 2 (or more?) for the same stretch of road. One for the shields, another for the name. Join them up in a query, or split shields and names handling everywhere and take what you need from the relevant geometries. The other biggy is dealing with the country borders during pre-processing, again no idea how to do this. You'd have to supply osm2pgsql with the relevant borders right off the bat, before it starts importing. That would mean 2 runs over the planet file (ouch!), or publishing a separate file with the relevant data. That is if you let osm2pgsql do the processing. As with coastlines, the country/state boundaries don't change drastically in the course of weeks, so an updated version of the regions could be generated every once in a while. OTOH, if osm2pgsql will only run some queries and let postgis handle the stamping of features with a proper field to filter on in the stylesheet, it can be done at the end of the import. The challenge to this method is in how to handle diffs. You wouldn't want to run through every geometry in your database everytime you import diffs, but only the changed ones. One more issue I see is what to do with features that cross these boundaries? Which style will/should they get? Should the import split them into 2 features, each on one side of the boundary? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
Martijn van Oosterhout wrote: I suppose it would be possible to get osm2pgsql to assign columns based on country locations, if the relevant polygons were available in Not just countries, but also states (different shields per state, for instance). Granted: same thing really. One more issue I see is what to do with features that cross these boundaries? Which style will/should they get? Should the import split them into 2 features, each on one side of the boundary? Tricky, not something that's going to be solved the first try. A little birdie once told me of a trick used by a certain map maker. Split the border-crossing road twice, so there is only a short section that actually crosses the border; probably less than 10 meters. Assign one of the styles to that short section, either randomly or by length or any other means. Because these sections are so short, it's not noticeable on a map, and you don't have style bleed. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
John Smith wrote: This is one reason to do these sorts of routes as relations instead of trying to cram lots of information into the way, you then should avoid overlapping shields if the rendering process is doing it's job. Relations hold a certain advantage in this case, but we have to consider the non-relation variants as well. If it's just ref numbers changing that shouldn't need anything more than to split the way would it? Indeed, but I'm thinking ahead here, to a situation where the style of the road itself would change at a border. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
John Smith wrote: They end up in the DB more or less identical, it just means 2 queries or a join etc instead of a simpler query. Now you're just thinking of a single renderer and its way of processing the data. Did you take osmarender into account? How does it handle the road relation at this point? As much as people always say to not tag for the renderer, we should also not design tagging specifically geared towards one specific renderer. Indeed, but I'm thinking ahead here, to a situation where the style of the road itself would change at a border. The suggestion you made to prevent style bleed sounds like tagging for the renderer, if that does occur the renderer should be fixed instead. Don't forget it's not that often that a road would cross a boundary and continue a long distance. Names change, refs change, maxspeed, surface, etc. We're already breaking it up for any number of reasons, at a border. But, a bit of preprocessing could also be involved, so that we don't do 'tagging for the renderer', if that makes people feel better. :P -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] trunk_link ref=*
Cartinus wrote: We (should) map what is there. So the real question is: Do sliproads between trunk roads actually have a ref in the real world? If I'm not mistaken, then they don't have one around here (the Netherlands). They do, at least between motorways. They are usually numbered the same as one of the motorways they connect to, followed by a letter. One of the reasons being that if something happens there, you don't have to explain emergency services where you came from and where you were going, but can just tell them the ref on the nearest marker. Say where the motorway has ref=A16, the motorway_link may be numbered ref=A16f. In Belgium, they can have refs too, but they seem to be a longer (internal?) version of the numbering scheme. For example, a motorway_link onto the R1 can have a ref of R001.427. Personally, I don't think these should be rendered on the main maps, and they should not be made up by us if there is no real ref on the ground. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] trunk_link ref=*
Dave F. wrote: Personally, I don't think these should be rendered on the main maps, osmarender:renderRef is a tag to prevent rendering. I said 'maps', plural. One renderer's trick of not showing certain features is certainly the wrong approach to this. and they should not be made up by us if there is no real ref on the ground. Would they not be essential for routing software? Why would you think that made up refs would be? Why would you even think that refs would be essential at all for routing? The only thing they are good for in the router is to give the driver better instructions. Take the next exit, and follow the A29 Now, if I'm on currently not on the A29, and I get this instruction, what is unclear about that? I see an exit coming up, probably even reinforced with signs pointing out that that is the direction to take for the A29. Clear and to the point. Take the next exit, follow the slip road A58-A29*, then follow the A29. Exactly how would this be better? A58-A29 won't be on signs, and it tells me non-essential information that could confuse me. * Assuming this is what we in OSM made up as a ref. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bot removing attribution tags
Matthias Versen wrote: A border-way should contain admin_level=X where X is the highest number of the border it represents and an boundary=administrative Tag. Lowest -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - landuse=orchard
Emilie Laffray wrote: That would mean that Mapnik needs to be checking a secondary field to determine what to display. If the renderer doesn't do that, you will end up with a map that is poorer in the end. In your case, that would mean That's not really so different as highway + access, or highway=service+service=*. And while it is nice to keep render complexity in mind when you design a tagging scheme, don't let it make a case against the more logical tagging. increasing the size of the table produced by osm2pgsql by one extra column. Overall, you are increasing complexity with little or no benefits. Which means 1 bit per row, for the most part. I am not sure it makes sense in the end since were are getting exactly the same of information if you are using the tag directly in landuse. Extensibility. Plain and simple. If you come up with a new category for agricultural=*, and while you wait for the renderers to pick that up, you're still getting a plain landuse=agricultural rendered. Not a white spot on the map. Data users that don't need the complexity of different agricultural uses only need to process the main landuse=agricultural tag, and not try to group various agricultural landuse types into 1. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Getting roles of relation's members in PostGIS using osm2pgsql
Ciprian Talaba wrote: Thank you about this info. I will probably start with the last approach (using planet_osm_rels and planet_osm_line tables) because this will keep my code separate from osm2pgsql. I will try to publish my tries because I believe others will be interested in something like this. Some code snippets that may be useful in your endeavours: Unnest an array. Later postgresql has this builtin, I think: CREATE OR REPLACE FUNCTION unnest(ANYARRAY) RETURNS SETOF ANYELEMENT LANGUAGE SQL AS $$SELECT $1[i] FROM generate_series(array_lower($1,1),array_upper($1,1)) i;$$; Unnesting a relation from planet_osm_rels gives you a list of all members, with the first character telling you what type of object it is, with the rest being the osm id. Unnest only way members of a relation in the planet_osm_rels table: CREATE OR REPLACE FUNCTION unnest_rel_members_ways(ANYARRAY) RETURNS SETOF ANYELEMENT LANGUAGE SQL AS $$SELECT substring($1[i] from E'w(\\d+)') FROM generate_series(array_lower($1,1),array_upper($1,1)) i WHERE $1[i] LIKE 'w%';$$; select unnest_rel_members_ways(members) as members from planet_osm_rels where id=your relation id; This gives you a list of only way ids, 1 per row, with the first 'w' character stripped. You still need some way to join the member role in the results. I didn't get that far when I wrote the unnest function, as I didn't need the role at the time. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] positioning of barrier = stile
David Groom wrote: I have been doing the former, but it appears this might stop routing applications allowing a car to travel from c - d as the barrier = stile blocks the road to vehicle transport, and so the second tagging option might be better. It seems you already answered your own question. Having the node with the barrier in the c-d road would make it also be a stile that is blocking travel in that road. I've used your 2nd tagging, with the node with the stile a small distance away from the connecting road. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] solved - why does mapnik not display my circles?
Kenneth Gonsalves wrote: that did not work either - I started moving the code around the file. Then in generate_images, I saw one circle peeping out from behing a building. So I moved the layer *after* the building layer - and there are my circles in all their pristine glory. I nominate this for the DUH! moment of the day awards. :D http://en.wikipedia.org/wiki/Painter%27s_algorithm -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] NoName
Ed Loach wrote: Resend to list (I loathe this ML for its reply functionality, but will not go further on that subject): Similarly, if you start your journey in an area where there are no signs, you are expected to know the speed limit already before you see any signs. Do other countries have speed limit signs on every way? That's not how I remember it from my brief visits to the USA and Crete (other holidays didn’t involve driving). Commenting on the NL situation: there are default speed limits for road classifications and where they are (inside or outside built-up areas). These can be overruled with posted speed signs, which only apply until a junction (motorway: on-ramp) in the road. After the junction (aptly called a 'decision moment' in pseudo-legalese) the sign has to be posted again if it differs from the road default. To overcome the multitude of signs, in many places they're now using a zonal application of posted speed signs, where the sign is the same, but it's framed on a rectangular sign with the word 'Zone' written above or under the speed sign. These apply until you've passed the 'end of zone' sign (with diagonal stripes). Only zone-30 is possible inside built-up zones (default: 50kph), and zone-60 outside (default: 80kph). Every other speed limit is posted with the regular signage regime. There have been cases where the zone was 'leaky' and you could enter it without having seen a sign. You'd have to document it fairly well if you got a ticket and wanted to legally challenge it, but that could succeed. The reason being: how could I have known, when I've encountered no signs? So, having a way to apply a speed limit to a broad range of roads (zones, built-up areas) and having a/various nation default(s) would be helpful. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Two lanes or...
Xav wrote: How should we map this ? http://www.youtube.com/watch?v=CeJ2vRQC7iY intoxicated=yes toxic_level=dangerously_high spirit=vodka fun=youbetcha -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] POI by coordinates
Tom Hughes wrote: the situation is: I've got a POI in the area where I'm only in summer. I've marked in somewhere in Google Maps and now I want to mark it in OSM. [snip] ...but bear in mind that importing data which has been derived from Google Maps is not allowed anyway! Even when someone has been there, verified the POI, and used Google Maps only as a fancy kind of notepad, in lieu of jotting down the coordinates on a piece of paper ? Of course, I understand, if he has placed the POI in Google Maps by checking their map and positioning the node from memory, this would not be usable for OSM. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
Frederik Ramm wrote: 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. There is one noticeable change here to clients: if they download such an ordered relation, and upload a newer version, they should have kept the ordering intact. The current unordered relations mean that a client can store it locally however it likes, and upload it in a completely different order, and it won't make one iota of difference to anyone. That assumption would become invalid. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maplint addr:
Russ Nelson wrote: Maybe somebody (me) who lives in the US (me) should get a copy of the code for keepright (me), put it up on their server (russnelson.com) and start analyzing the US data? That's been done for Australia as well, so I think this would be the right thing to do. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When will the next mapnik coastline update be?
Peter Körner wrote: Yes, the processed_p is available from [1], where it is generated every now an then (manual step). Then, it has to be updated at the osm mapnik server, which, again, is a manual step. This is not entirely true. The Coastline Error Checker runs through all the coastlines every every* night, generating a processed_p shapefile, but this version is not used by the OSM mapnik map. The latter generates its own coastline shapefile every time the full planet is reloaded, which happens on an infrequent schedule. So there are at least two people involved that are not working in an planned time schedule (as nobody pays them for this, i think). Fortunately, the coastline doesn't change that often ;) More often than you may think, as existing OSM data is refined, or sand suppletion or depletion is performed, either by nature or by man. * When hypercube isn't down or otherwise slow, which is quite often these days. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
