Re: [OSM-talk] Is Xapi working?
Hello Roland, Currently, I'm also experiencing some problems with the XAPI, but it looks like OSM3S is going to suit my needs even better. It looks very promising. However, I do know if all my XAPI queries can be converted to OSM3S already, or that not all commands are implemented yet. A query is: api/0.6/node[rcn_ref=*][bbox=2.7984557419334006,50.62642256377723,7.388298070963748,53.954129036190224] The bbox thing might be replaced with containment in area 3600047796. The things that I would like to know are: - Is it possible to query for key presence? I only know how to query for key-value pairs. - Can I intersect a kv query with a region query? I only saw the availability of union, not any kind of intersection. Thank you very much, Steven Roland Olbricht schreef: This happened over the weekend too. The request this time was http://osmxapi.hypercube.telascience.org/api/0.6/node[amenity=studio] You can try to use the OSM Server Side Script server. Just try on the command line wget -O studio.nosm --post-data=query type=\node\has-kv k=\amenity\ v=\studio\//queryprint mode=\body\/ http://78.46.81.38/api/interpreter (all on a single line) or run in you favourite browser http://78.46.81.38/api/interpreter?data=%3Cquery%20type=%22node%22%3E%3Chas-kv%20k=%22amenity%22%20v=%22studio%22/%3E%3C/query%3E%3Cprint%20mode=%22body%22/%3E (entire URL on a single line) This returns a gzipped file with all results. The service is less up-to-date (designed to be 4 to 6 hours behind) and does not contain edit metadata (timestamp, uid of editor, version) but depending on your needs it still might help. Cheers, Roland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] tileserver in RDnew?
Als je de aarde op iets anders afbeeld dan een bol, gebruik je een kaartprojectie, dus zelfs Marble gebruikt een projectie, alleen is daar de vertekening minimaal, omdat het er uit ziet als een bol en je dus ook de wereld niet in zijn geheel kunt zien. Het kiezen van de projectie is vooral afhankelijk van het doel van je kaart. Iedere projectie behoudt bepaalde eigenschappen en vertekent andere. Martijn doet vermoeden dat je een conforme projectie nodig hebt om te zorgen dat de gehele wereld er correct uit ziet, dat is echter niet zo. Een conforme projectie is een projectie die hoekgetrouw is. Op een Mercatorprojectie is dan ook een rechte lijn een constante kompaskoers, wat deze kaarten zeer geschikt maakt voor de zeevaart. De schaal verloopt echter met de breedtegraad en de kortste weg is niet een rechte lijn. Het is ook mogelijk om kaarten te maken die afstandsgetrouw zijn, dit is gebruikelijk voor wegenkaarten. RD is een voorbeeld van een afstandsgetrouwe projectie die alleen rond Nederland werkt. Er geldt altijd dat als je verder inzoomt, de vertekening kleiner wordt. Het voordeel van een standaardprojectie zoals OSM die op dit moment heeft, is dat iedereen er mee kan werken. Dus als je andere toepassingen hebt, is het de vraag of je hiervoor echt een andere projectie nodig hebt en welke je dan wilt gebruiken. Er zijn zeker toepassingen waarvoor een andere projectie onvermijdelijk is, maar hou er wel rekening mee dat veel software alleen voor de huidige projectie is gemaakt en maak op basis daarvan een keuze. Steven Martijn van Oosterhout schreef: 2009/1/14 Gert Gremmen g.grem...@cetest.nl: Wat is precies de relevantie van het type projectie in een digitale kaart ? Je moet een projectie kiezen. Of je kan iets als Marble kiezen, dan heb je puur 3D en is de projectie niet meer nodig. Zeker als de verschillen (naar ik veronderstel) op NL schaal alleen met een (krom) maatlatje gemeten kunnen worden ? Toch ? De wereld bestaat alleen uit kromme lijnen. Maar mensen houden van rechte lijnen :) dus projecties spelen daarop in. Zijn er nog argumenten die ik mis, waarom bijvoorbeeld nr 28992 beter zou zijn dan 3785... Google mercator heeft het voordeel dat het makkelijk is om mee te werken en even goed werkt wereldwijd. En het is conformal. Ik weet niet of 28992 conformal is, maar ik denk niet dat de VS er goed uit zou zien in 28992. En alles op de zuidelijk halfrond kan helemaal niet in 28992. Meeste per land projecties zijn alleen goed voor die ene land, wij moeten werken met wereldwijde datasets. Have a nice day, ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Maritme borders
IMO, the proposal of Gustav is better, because maritime borders clearly are administrative. Martijn suggests that there is a clear difference between country and maritime borders. However, it are different properties of a border: a border can be one or both. The half of the Dutch country border is a maritime border. So I would propose to use boundary=administrative on all maritime borders and use another tag to distinguish them. Currently, borders are distinguished by admin_level. The wiki tells about admin_level: admin_level http://wiki.openstreetmap.org/wiki/Key:admin_level=1 to 10 has been introduced in order that different borders can be rendered consistently among countries (doing this based on border_type would require knowledge of their hierarchy in each country). Based on this information, I conclude that every border has a border_type, but we tag it as admin_level for convenience. For example: border_type=province and inside(The Netherlands) implies admin_level=4. We mainly tag the admin_level only, because that one is the easier for rendering, but we think about it as border types and sometimes tag border_type too. So I would propose to use border_type for any border that has no admin_level defined. Thus the territorial sea will have admin_level=2 because it's a country border, but any other maritime border will only have border_type set. That works quite well with the current tagging: border_type is optional when admin_level is set, required otherwise. Also for rendering it's no problem: render borders based on admin_level and when that one's empty, use border_type. The only thing that remains is: which border_types are possible? Probably exclusive_economic_zone will be one of them. Steven Gustav Foseid schreef: On Thu, Jan 1, 2009 at 6:45 PM, Martijn van Oosterhout klep...@gmail.com mailto:klep...@gmail.com wrote: boundary=maritime? or something like: boundary=administrative admin_maritime=territorial ? - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] kaarten met wat beperktere informatie
Hallo Gert-Jan, Het zelf maken van kaarten is redelijk wat werk. Je moet namelijk ook nog zelf de stylesheet maken en tiles renderen voor het in OpenLayers te gebruiken is. Wat voor jouw waarschijnlijk wel interessant is, is dat ik al een kaart heb gemaakt die ik zelf bij het zeilen gebruik. Deze kaart is nog niet af, maar er staat al wat leuks op: http://squall.student.utwente.nl/betonning/waterkaart.html. Mocht je zelf nog leuke ideeën hebben voor een waterkaart, dan ben ik daar wel benieuwd naar. Groeten, Steven Gert-Jan Braas schreef: Hoi, ik ben me wat aan het orriënteren op het gebruik van Openstreetmap i.c.m. OpenLayers. De bedoeling is dat er een kaart gebruikt wordt met een focus op vaarwegen. Is er ergens een pagina of een Howto die uitlegt hoe ik de tile-server kan aanroepen zodat ik aangepaste afbeeldingen kan verkrijgen? De bedoeling is: duidelijk aangegeven vaarwegen, met wat minder 'wal gegevens' en die ook in een lichtere kleur weergegeven. Of moet ik dan een eigen tile-server in elkaar zetten. bij voorbaat dank, Gert-Jan Braas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] verschil OSMrenderer / Mapnik, lauwersmeer ziet er wat vreemd uit.
Waarschijnlijk komen alle problemen met Osmarender door de oceantiles.dat. Op http://server.tah.openstreetmap.org/Browse/slippy/ kan je deze als laag aanzetten en dan zie je dat alle tiles met problemen inderdaad niet als land in oceantiles.dat staan. Er zijn veel fouten in Nederland, dus iemand die weet hoe de oceantiles precies werken moet er maar eens naar kijken. Het verdwenen water in Mapnik komt misschien omdat dit een ingewikkeld water is dat m.b.v. een multipolygon is aangemaakt. Ik zou ook niet weten hoe dat precies moet, dus daar moet ook nog iemand die er meer verstand van heeft naar kijken. Steven Ldp schreef: Matthijs Benschop wrote: Er zijn wel meer gekke dingen mbt water aan de hand: Zie utrecht en links van woerden: http://www.openstreetmap.org/?lat=52.079lon=4.9768zoom=13layers=0B00FTF En verdwenen water in mapnik: http://www.openstreetmap.org/?lat=52.0999lon=4.8731zoom=14layers=B000FTF Kijk ook eens boven Amsterdam en bij Muiden. De [EMAIL PROTECTED] client gebruikt het oceantiles bestand , waarin wordt bijgehouden wat de basis van een tile is, land/ocean/mixed, en ik vermoed dat dit de oorzaak is? Oftewel: iemand heeft deze tiles op ocean gezet. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] QA admin_level=2
De grenzen van Nederland zien er nu wel goed uit, maar de zeegrenzen kloppen nog niet. Als ik het goed heb liggen de gemeentegrenzen 1 km uit de kust, dat is waar ze nu staan, maar de staatsgrens ligt 12 mijl uit de kust en dus niet op de gemeentegrenzen. Deze moet dus nog worden aangemaakt. Verder ligt buiten deze territoriale wateren nog de Exclusieve Economische Zone (EEZ). Deze vind ik persoonlijk minder belangrijk, maar het zou wel mooi zijn als we ook daarvan de grens er in kunnen zetten, maar dan moeten we wel beslissen hoe we die taggen. Verder weet ik niet hoe we aan al deze grenzen kunnen komen, maar de staatsgrens 11,5 mijl de zee in verplaatsen lijkt mij wel te doen. Steven Skywave schreef: Upload klaar, nu kunnen de nodes weer gewoon veranderd/verwijderd worden. Zal nu beginnen met het deleten van de achtergebleven nodes 2008/10/25 Skywave [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Geen bot maar JOSM + osmxapi, maar veel 412 errors omdat er kruispunten zijn gemaakt tussen wegen en grenzen. Verzoek om even niks te verwijderen omdat de import loopt van de nieuwe grenzen en anders daar 412 errors bij komen. Als de nieuwe data erin zit zat ik daar aan werken. Ook heb ik nog een last minute wijziging aangebracht in de data, ik heb de grenzen die provincegrens en gemeentegrens zijn de tag admin_level:8=yes en admin_level:4=yes gegeven zodat het mogelijk blijft om alle gemeentegrenzen te blijven renderen. 2008/10/25 Lambertus [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Ik zie dat je begonnen bent met het verwijderen van de provincie grenzen. Nu zijn er alleen een heleboel nodes achtergebleven, waarschijnlijk een bugje in je bot? Skywave wrote: Hier is bestand zoals ik het dan zou uploaden: http://skywave0.googlepages.com/osmborders.zip . Als niemand er bezwaar tegen heeft dacht ik er over om voor de volgende planet dump de import te beginnen. -- Thomas ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] [Tagging] leisure=ice_rink
Well, I was talking about natural ice rinks. They have only a few days a year ice, but there is some infrastructure. Most of them have lights, a small building where you can buy drinks when there's ice and some machines to prepare the ice. (One can recognise them even during summer.) Thus, I would tag them as leisure=ice_rink too. However, because they are quite different from artificial ice rinks, an additional tag to distinguish them would be useful. Steven Mathieu Clément schreef: Good evening, please revote not for sport=ice_rink (because rink is not a kind of sport...) but for leisure=ice_rink, which is better. I have no idea about how to tag it as a building (usually where spectators can watch an ice hockey game) or as a open ice rink (small, where ~20 children can skate on it) = some people talk about natural ice rinks, but I can't understand how to tag it, since there is no infrastructure and that icing only happens a few days or so. Cheers, Mathieu ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] leisure=ice_rink
That's nice. I would like to see it listed as a useful combination with a short explanation on the ice_rink page. That way everyone knows about the usage and no new tag is required. Steven Cartinus schreef: On Saturday 04 October 2008 09:35:51 Steven te Brinke wrote: However, because they are quite different from artificial ice rinks, an additional tag to distinguish them would be useful. seasonal=yes That tag is already in use for other things that are there only part of the year and depend on the weather. One seasonal ice rink in Tull en 't Waal: http://www.openstreetmap.org/?lat=51.995615lon=5.149044zoom=18layers=B000FTT ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetBugs
It looks like updates done by the script are not fully correct. Deleting results in an empty balloon and still existing node. However, after refreshing it is correct. When adding a bug, it disappears when I hit OK. However, at that moment the bug I added before appears. Thus I always miss the last one added, but see all others. (I'm using FF3.) Besides that, it is very nice. Steven [EMAIL PROTECTED] schreef: Hello I just made a tiny tool for fun : http://gpsrevolution.blogspot.com/2008/06/openstreetbugs-eng.html That's not a big thing but I found it useful. Feel free to use it. Xav (french mapper). Very Cool. Deleting doesn't seem to work properly and if you add a bug when POI layer is disable you can enter details but it does not stick. In terms of usage where is the list of bugs maintained and can it be automatic split down into regions? There nothing like a bit of competition to get local teams motivated (my list has less bugs than yours...). Since we have mailing lists for different countries, would that be a suitable split? How about changing the marker to be a bug outline :-) Cheers, Simon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapnik PointSymbolizer question
Well, that works with a TextSymbolizer, but I can't get it working with a PointSymbolizer. Steven Steve Chilton schreef: Never had occasion to do that but sure it is possible. To move the TextSymboliser something like this moves label 8 pixels above the symbol: Rule MaxScaleDenominator5/MaxScaleDenominator MinScaleDenominator25000/MinScaleDenominator Filter[railway]='station'/Filter TextSymbolizer name=name face_name=DejaVu Sans Bold size=9 fill=#000 dy=-8 halo_radius=1 wrap_width=0/ /Rule Use of similar dy=xx command (or dx=+/- to move in horizontal direction) would work in PointSymbolizer command Cheers STEVE -Original Message- From: [EMAIL PROTECTED] on behalf of Steven te Brinke Sent: Mon 4/7/2008 8:33 PM To: talk@openstreetmap.org Cc: Subject: [OSM-talk] Mapnik PointSymbolizer question Hello, Does anyone know if it is possible in Mapnik to place a PointSymbolizer at some offset from the point instead of centering the image above the point. Thanks, Steven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Mapnik PointSymbolizer question
Hello, Does anyone know if it is possible in Mapnik to place a PointSymbolizer at some offset from the point instead of centering the image above the point. Thanks, Steven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Mapnik: amenity=bus_station
Hello, The current mapnik rules will render amenity=bus_stop, but the map features define it as amenity=bus_station. Steven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Lighthouses
Hello, It's a good idea to tag buoys, but there are very many types. So you should think carefully about what you want and what you don't want to tag. I've extracted a list of types from the Dutch Notices to Mariners: http://squall.student.utwente.nl/betonning/types.xml. It shows quite some possible types. Please don't copy the images from this page, as I don't know if these have any copyright. Besides that, IMO starboard and port are not a good way to specify the type of a buoy. That is because in the Netherlands buoys are placed in the downstream direction, with green at the port side. However, at sea they are placed towards land, with green at the starboard side. So in fact you don't see the difference, only the definition is different. That's why starboard and port are not well defined. Steven Steve Hill schreef: On Wed, 2 Apr 2008, OJ W wrote: Tagging notes/discussion is at: http://wiki.openstreetmap.org/index.php/Talk:Tag:man_made%3Dlighthouse If anyone has comments on the tags etc, then please do join the discussion I've put together a bare-bones proposal for tagging buoys: http://wiki.openstreetmap.org/index.php/Proposed_features/Buoy I'd appreciate input, comments, etc. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Lighthouses
In that case we really need to tag both colour and starboard/port, because in the Netherlands we use SIGNI, that has green conical buoys at port. Steven Steve Hill schreef: On Thu, 3 Apr 2008, Nick wrote: You should record colours red/green, not starboard/port. It's probably quite dangerous not to. Port lateral buoys have a flat top, starboard ones are conical - this is the same in both systems. But the colours do indeed change. So we probably need to record both port/starboard and the colour. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] Reminder: Mapping Party Enschede, komend weekend!
Helaas heb ik het ook druk dit weekend, zaterdag en zondag feest :-) . Anders was ik er graag bij geweest. Steven Rob schreef: hier hetzelfde, datum is ongelukkig anders had ik een mooi motor ritje kunnen maken. net voor m'n wintersport plannen is niet handig ;) Op 15-02-08 heeft *Lambertus* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] het volgende geschreven: Ik zou heel graag willen komen naar mijn oude studie stad maar zaterdag heb ik een familie uitje en zondag ga ik m'n zusje op het vliegtuig zetten en zit ik dus in het uiterste westen i.p.v. het uiterste oosten... Martijn van Exel wrote: Ha allemaal, Even een reminder (ook omdat ik nog maar weinig inschrijvingen zie op de wiki): Komend weekend vindt er een Mapping Party plaats in Enschede. We zijn te gast bij onze sponsor JR Online. Een uitgelezen kans om je OSM-collega's (weer eens) te ontmoeten en met het verwachte mooie weer de kaart van Enschede een stukje beter completer te maken. De party heeft ook een technische 'side track': met JR Online, die onze eigen tileserver host en sponsort, zullen we het gaan hebben over de verdere ontwikkeling van de server, wensen en plannen. Iedereen die daar over mee wil praten is natuurlijk meer dan welkom. Zie http://wiki.openstreetmap.org/index.php/Netherlands_Mapping_Parties_2008 voor alle info en om aan te geven dat je komt. Hopelijk tot zaterdag of zondag! ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Wat zijn de voordelen hiervan? Ik kan me voorstellen dat het snellere parsers zijn; nu gaat het niet heel snel maar ik vind een halve minuut nog best acceptabel. Ik kan me niet voorstellen dat ze veel minder geheugen gebruiken als ze dezelfde datastructuur maken (DOM). Dus ik zie niet in dat ze het geheugenprobleem op kunnen lossen. Verder lijkt het mij geen probleem als een programma voor een eenmalige import nogal lang nodig heeft om te draaien. Zelfs als ik het een uur zou moeten laten draaien, zou ik daar geen problemen mee hebben. Het is toch eenmalig. Als je echter te weinig geheugen beschikbaar hebt, gaat dit niet lukken. Dus daar zul je iets aan moeten. Persoonlijk gaat mijn voorkeur nog altijd uit naar Java, omdat ik daarin veel sneller een programma kan schrijven. Maar voor de c kenners is een iets snellere implementatie in c natuurlijk wel een goede keuze. Steven Stefan de Konink schreef: Heb je wat je wilt doen al eens geprobeerd met expat of msxml? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Coördinaten zijn niet makkelijk de sorteren, omdat ze 2-dimensionaal
zijn. Hiermee heb ik ook niet zo veel ervaring. maar ik heb eens
nagedacht wat volgens mij een aardig algoritme is. Ik zal beschrijven
hoe ik het zou implementeren:
Stel we hebben een aantal punten P die niet in OSM zitten. Dan bepalen
we de bouding box van deze punten en nemen alle punten Q die in OSM in
deze bouding box zitten (hierbij kun je je eventueel beperken tot alle
punten met een highway tag).
L := lijst van punten uit Q gesorteerd op OL
p := element uit P, dus punt waarvan we dichtstbijzijnde punt uit Q
willen weten
i := punt met |p.OL - L[i].OL| zo klein mogelijk, deze kun je in
logaritmische tijd vinden
d := afstand(p, L[i])
q := L[i]
j := i + 1;
while ( |p.OL - L[j].OL| d ) {
d2 := afstand(p, L[j])
if ( d2 d ) {
d := d2
q := L[j]
}
j += 1
}
j := i - 1;
while ( |p.OL - L[j].OL| d ) {
d2 := afstand(p, L[j])
if ( d2 d ) {
d := d2
q := L[j]
}
j -= 1
}
return q
Dit algoritme is natuurlijk nog niet volledig, zo moet je nog nadenken
over een paar punten:
* |p.OL - L[j].OL| heeft waarschijnlijk een andere eenheid dan d, dat
moet je even omrekenen
* eventueel kun je in deze while loop i.p.v. tegen d, degen minimum(d,
MAX-AFSTAND) controleren
* ik heb het hier over een gesorteerde lijst, maar een boom zou ook
kunnen, als je er maar in order doorheen kunt lopen (een boom laad wel
veel sneller dan een lijst, maar aangezien je hier één keer deze
lijst/boom laad en daarna voor alle punten de dichtstbijzijnde kunt
vinden, is de snelheid van het laden niet heel belangrijk)
Mocht je nog een werkende XPath versie hebben, dan hoor ik graag of de
snelheid nog een beetje goed was. De ervaring die ik ermee heb, is dat
het niet heel snel is. Maar dat kan natuurlijk ook (gedeeltelijk) liggen
aan de implementatie die ik gebruik. Misschien heb jij een snellere parser.
Steven
Rob schreef:
hoe wil je dit gaan sorteren.. b/r-tree ? geef eens een hint
ondertussen ga ik xpath eens pesten
Groeten
Rob
Op 07-02-08 heeft *Steven te Brinke* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
Hallo,
XPath is wel heel krachtig, maar niet heel snel. Ik denk dus dat
het gebruik van een gesorteerde lijst een beter idee is. Zelf heb
ik nog nooit .net gebruikt, dus daar heb ik niet zo veel verstand
van. Maar mocht het niet lukken, dan wil ik wel iets in Java
schrijven. Daarmee lees ik nu ook al OSM bestanden in.
Groeten,
Steven
Rob schreef:
ik heb die wpned-zuid.gpx (1701 waypoints) eens tegen de
places.osm (8875) laten draaien, om een indruk te krijgen van
performance
en dit is een stukje output
...
wpt 52C37 close to Pannenschop @ 587m
wpt 52C39 close to Vreewijk @ 300m
wpt 52C43 close to Leensel @ 714m
wpt 52C44 close to Leensel @ 1885m
wpt 52C45 close to Heitrak @ 2708m
wpt 52C46 close to Ommel @ 50m
er wordt dus voor elk wapoint in de gpx de kortsbijzijnde plaats
node gevonden in de osm file, hiervoor loopt een dubbele foreach
loop, deze berekent de afstand tussen waypoint en node
de search loop begint nu al te kraken (lees 155 seconden)
aangezien we nu al 15miljoen itteraties hebben.
ik ben een andere manier aan het bedenken
bereken van elk waypoint de 5meter boundingbox coordinaten en
laat de node selectie door xml parser (xpath) doen, dit moet
veel efficienter zijn.
Op 07-02-08 heeft *Rob* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
dank u, heb nu de netherlands.osm van 600MB
dat wordt flink stampen voor xml parser ;)
Op 07-02-08 heeft *Lambertus* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] het volgende geschreven:
Rob wrote:
weet iemand (kleptog?) de locatie van de nederlandse osm
file ?
heb even op de wiki rondgekeken maar helaas nog niet
gevonden
Hier staan allemaal up-to-date excerpts:
http://download.geofabrik.de/osm/europe/
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk-punten automatiseren?
Hallo, XPath is wel heel krachtig, maar niet heel snel. Ik denk dus dat het gebruik van een gesorteerde lijst een beter idee is. Zelf heb ik nog nooit .net gebruikt, dus daar heb ik niet zo veel verstand van. Maar mocht het niet lukken, dan wil ik wel iets in Java schrijven. Daarmee lees ik nu ook al OSM bestanden in. Groeten, Steven Rob schreef: ik heb die wpned-zuid.gpx (1701 waypoints) eens tegen de places.osm (8875) laten draaien, om een indruk te krijgen van performance en dit is een stukje output ... wpt 52C37 close to Pannenschop @ 587m wpt 52C39 close to Vreewijk @ 300m wpt 52C43 close to Leensel @ 714m wpt 52C44 close to Leensel @ 1885m wpt 52C45 close to Heitrak @ 2708m wpt 52C46 close to Ommel @ 50m er wordt dus voor elk wapoint in de gpx de kortsbijzijnde plaats node gevonden in de osm file, hiervoor loopt een dubbele foreach loop, deze berekent de afstand tussen waypoint en node de search loop begint nu al te kraken (lees 155 seconden) aangezien we nu al 15miljoen itteraties hebben. ik ben een andere manier aan het bedenken bereken van elk waypoint de 5meter boundingbox coordinaten en laat de node selectie door xml parser (xpath) doen, dit moet veel efficienter zijn. Op 07-02-08 heeft *Rob* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] het volgende geschreven: dank u, heb nu de netherlands.osm van 600MB dat wordt flink stampen voor xml parser ;) Op 07-02-08 heeft *Lambertus* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] het volgende geschreven: Rob wrote: weet iemand (kleptog?) de locatie van de nederlandse osm file ? heb even op de wiki rondgekeken maar helaas nog niet gevonden Hier staan allemaal up-to-date excerpts: http://download.geofabrik.de/osm/europe/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Nieuwe Kaart van Nederland bij Landroof
Mooie kaart, vooral de kaarten op de achtergrond zijn ook erg mooi, hoewel deze wel minder actueel zijn. Op de site staat: Mits niet anders vermeld valt de inhoud van deze website onder een Creative Commons Licentie http://creativecommons.org/licenses/by/2.5/nl/. en aangezien ik nog geen andere licentie heb gezien, zou ik hieruit concluderen dat alle kaart-data tevens cc gelicenseerd is. Ik kan het mij echter nauwelijks voorstellen, dus misschien kunnen we het navragen, want aan die kaarten kunnen we veel hebben. Steven Bas de Lange schreef: Beste Talk-ers, Ter info: Op de Nieuwe Kaart van Nederland ( http://www.nieuwekaart.nl ) zag ik dit bericht: 31 januari 2008 Op 7 februari 2008 zal het VPRO programma Landroof ( http://www.landroof.nl/ )aandacht besteden aan de Nieuwe Kaart van Nederland. De uitzending begint om 19:25 op Nederland 2. De _webstek_ van Nieuwe Kaart van Nederland is, volgens hun webstek, Creative Commons-naamsvermelding-gelicenseerd. In hoeverre dit alleen op de webstek zelf slaat of ook de kaart-data zelf, weet ik niet. De Nieuwe Kaart van Nederland is een initiatief van het Ministerie van VROM en het Nirov. Het projectbureau is gehuisvest bij het Nirov en wordt financieel ondersteund door VROM. De Nieuwe Kaart van Nederland biedt een landsdekkend totaaloverzicht van ruimtelijke plannen; een blik op de toekomst van uw eigen omgeving. De Nieuwe Kaart van Nederland laat zien waar het Nederlandse landschap in de toekomst zal veranderen. Hieronder vindt u meer informatie over de organisatie. (zie verder webstek) Bas! ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] [Meedenk] OV penetratie kaart
Het planningsalgoritme lijkt mij een simpel zoekprobleem, waarvoor ik wel een applicatie wil schrijven. Het lastige lijkt mij het verzamelen van de data. Haltes en routes zijn nog wel redelijk te doen denk ik, maar tijden zijn een stuk meer werk, omdat deze vaker veranderen en best wel ingewikkeld zijn. Dus er zal eerst een goed doordacht voorstel voor het taggen hiervan moeten worden gemaakt. Zodra er genoeg data bekend is om een beetje te kunnen plannen, wil ik wel aan de applicatie gaan werken. Het prijsverschil tussen chip- en strippenkaart lijkt mij een stukje makkelijker, omdat je hiervoor geen tijden alleen routes nodig hebt. Hoe goed/slecht bereikbaar een gebied is, is ook wel leuk om te bekijken. Voor de treinstations heb ik al een keer zoiets gemaakt, maar als we alle gegevens van busroutes hebben, kan dat nog een stuk mooier. (Dit is te vinden op http://squall.student.utwente.nl/reistijd/kaart.svg maar werkt volgens mij alleen in Firefox.) Steven Skywave schreef: Lijkt een goed idee, maar is er dan al een tag afgesproken voor de busroutes? In ieder geval heb ik vandaag even Kosmos gehackt om de busbanen in Almere weer te geven. http://nl.wikipedia.org/wiki/Afbeelding:Almerebusbanen.png . De busbanen (helemaal afgesloten voor verkeer) zijn getagd met psv=yes bus=yes emergency=yes highway=service. Ze zijn helaas niet echt herkenbaar in Osmarender en Mapnik en het maakt het moeilijk om ze herkennen. 2008/2/2 Stefan de Konink [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hoi allen, Met dit mailtje wil ik een meedenk project starten voor een idee wat ik in m'n hoofd heb en waar ik van denk dat het voor OSM nederland best interessant kan zijn. Ik denk dat het maken van een kaart waarin alle vaste vervoersmogelijkheden opgesloten zijn een enorme push kan geven voor alternatieven aan 9292OV dan wel eenvoudigere toegang op basis van plaats bepaling. Mijn idee is om een data collectie te verzamen waar in volgorde van belangrijkheid: - De route van bus, tram, metro, trein, draagvleugelboot, etc. opstaat - De haltes opstaan - De tijden van de haltes (eventueel met heuristische functie) Dit zou ik in eerste instantie willen aanbieden als een layer over Nederland. De routes zouden gebruik moeten maken van de wegen die bestaan. En het taggen ervan plaats laten vinden door een collectie van nodes te selecteren en op basis van verbonden volgorde op te slaan. Dit houd impliciet een sequentie in en betekend ook dat er in de achtergrond een actieve check moet blijven plaatsvinden op verbondenheid als de kaart wordt bewerkt. Als alternatief zouden de routes alleen uit haltes kunnen bestaan, met eventuele routerings hints. Buiten mensen die de routes van hun bus willen taggen, danwel door in de bus te zitten of door te weten hoe de bus rijdt. Heb ik iemand nodig die dit voor Maknik kan maken. De applicatie zou zijn: - Ik sta op punt X - Ik wil naar locatie Y - Wat moet ik doen om er te komen In dat geval zouden op basis van kosten functies een bereking gedaan moeten worden of het beter is om een stukje te lopen, of dat je direct in een bus kunt springen. De meerwaarde ten opzichte van 9292OV is dat de applicatie volledig geoptimaliseerd kan worden op mobiel gebruik. Daarnaast geeft de kaart ook de penetratie van OV aan, wat zoveel wil zeggen als: dit gebied is goed danwel slecht bereikbaar. Ik voorzie daarbij een mogelijk persmoment waar we kunnen aangevel welke plek in Nederland het beste en welke het slechtste bereikbaar is. Uiteraard komt er nog wat om de hoek. Samen met de OV-Zone kaart kunnen we gaan aangeven wat het prijsverschil tussen strippenkaart en OV-chipkaart is. Dat is ook best *hot* lijkt me. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Regular Expression
Hallo, Alles wat in de XML staat is UTF-8 en dus is het beter om de uitvoer op UTF-8 te zetten, want dan blijft de encoding gelijk, anders moet deze worden omgezet tijdens de XSLT transformatie. Op mijn pc werkt het ook als ik encoding op UTF-8 zet. Het probleem is waarschijnlijk dat je server zo ingesteld is dat deze met een header doorgeeft dat de encoding iso-8859 is. Je zult dus even moeten kijken of de instellingen van de server correct zijn. Groeten, Steven Rob schreef: tja of ik doe nog iets correct, het moet dus utf-8 zijn ?.. zie ook geen encoding in de osmxapi xml hier kun je trouwens output van die xslt bekijken http://burghthof.nl/osm/osm2htm.php 2008/2/1, Stefan de Konink [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rob schreef: ik denk het ook utf-8 mag zijn, zal eens kijken of dat beter uitziet, nee dus, dan krijg ik : Bökkenlaand en met iso-8859 : Bökkenlaand Dan zijn er n00bs bezig geweest met de verkeerde encoding. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHovUxYH1+F2Rqwn0RCt95AJ9pga09LYj0UEHpJeIbA51pxQGkgACfRiyk wLlBbrKiMiRykKGd9EpA36E= =0+wk -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Automatische lijst met carnavalsnamen
Ziet er goed uit. Je leert iig snel, dat is mooi :-) . Alleen naar mijn
mening kan de php code nog wat simpeler, het onderstaande bereikt
hetzelfde, maar is een stukje korter. Neemt niet weg dat jouw code ook
een goede oplossing was.
Steven
?php
$lines =
file('http://www.informationfreeway.org/api/0.5/node[name:carnaval=*][bbox=3.0,50.65,7.15,53.55]');
$lines[0] = '?xml version=1.0 encoding=UTF-8 ?' . \n .
'?xml-stylesheet type=text/xsl href=carnaval.xsl ?' . \n;
$contents = implode('', $lines);
$contents = str_replace('#38;apos;', 'apos;', $contents); //remove
#38; from #38;apos;
$myFile = 'carnaval.xml';
$fh = fopen($myFile, 'w') or die(can't open file);
fwrite($fh, $contents);
fclose($fh);
?
Joris Meijerink schreef:
Voor iemand die tot gisteren nog reg exp. wilde gebruiken om zijn .osm
file vorm te geven denk ik niet dat ik het slecht heb gedaan,
http://scout.kvz.tudelft.nl/osm/carnaval.xml :)
Het was even de logica vinden van xsl, maar het werkt idd lekker.
Wordt automatisch mbv php elk half uur geupdate,
http://scout.kvz.tudelft.nl/osm/update.phps
De htmlentitie apos; wordt ook aangepast, neemt niet weg dat het op de
server dus nog wel fout gaat.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsersbond lanceert fietsroute planner voor Gelderland
Klinkt interessant, alleen werkt de pagina met de Gelderland planner bij mij niet helemaal (hij wordt slecht een kwart van de hoogte van mijn browservenster, waardoor ik er nauwelijks iets op kan zien). Natuurlijk heeft de Fietsersbond wel betere informatie dan OSM heeft, voor dat bedrag kun je wel wat kopen, en een leuk planningsalgoritme voor fietsers. Maar er is ook veel door vrijwilligers verzameld. Ruim honderd ervaren fietsers leverden er de afgelopen maanden de benodigde gegevens voor. Nu weet ik niet hoe deze informatie is aangeleverd en of de vrijwilligers deze informatie nog hebben, maar als wij deze informatie ook kunnen bemachtigen, zou dat heel mooi zijn. Steven Lambertus schreef: Dit klinkt als een persbericht (jaja, ik weet er nu alles van!) en dat is het ook. De Fietsersbond lanceert dus een fietsroute planner voor de Provincie Gelderland nadat zij daarvoor een subsidie van 100.000 Euro had ontvangen. http://www.destentor.nl/apeldoorn/article2562664.ece Mijn eigen commentaar: Da's niet slim van de provincie, voor een twaalfde deel hadden wij hetzelfde kunnen doen :P ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk] Bridges / viaducts for railways
Hello, As a sailor I like to know if a bridge is a moveable one, and I think this is also interesting for cars, because they might need to wait. So I agree that bridge=true is not enough, I would like to be able to have a bridge=moveable. It is also possible to add the type of bridge (lift, swing, bascule, ... - wikipedia has some beautiful animations of them: http://en.wikipedia.org/wiki/Moveable_bridge). So I think a viaduct=yes or a viaduct=type would be a good idea. At least the current way viaduct is used doesn't seem to be a good one. And I think a viaduct and a bridge are quite different things, so it's no problem to give them their own tag. Steven Dave Stubbs schreef: That's usually the plan I think. The main problem we have with putting this into practice, is that to maintain an optimal number of tags we need to know the entire tagging domain before we start... which we don't. So taking your example, if instead of bridge=yes we allow bridge=suspension, we don't actually have a problem (assuming everybody agrees to assume the existence of the bridge tag implies a bridge regardless of the value, maybe excluding no). But if we had started with transit=bridge/tunnel/ferry, then we'd still need the bridge tag anyway because it's probably not sensible to add the transit=suspension_bridge etc, simply for the ease of processing. Ofcourse you could argue we need the transit tag, and just don't have it. I think for many of these things where we have x=yes/no, we find that there is often a number of subtypes that could be substituted for the yes. Although most people probably wouldn't know how to classify them, and just want to record the main type. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] carnaval forum
De zoekfunctie op openstreetmap.org geeft bij het invoeren van een plaatsnaam als eerste resultaat vaak de precieze locatie van deze plaats op de kaart, dus dat maakt het vinden van een plaats als je alleen de naam hebt een stuk makkelijker. Steven Joris Meijerink schreef: Ha, niet heel erg makkelijk. Ik denk dat voor eindgebruikers we ons moeten beperken tot vragen van hoe die heet in het nederlands en wat de carnavals naam is and dan doen wij de correlatie. Alleen het opgeven van de namen is net te weinig, dan zoek je je soms helemaal rot. Als we ook een lon en lat hebben, die zo is af te lezen in de hoek van de pagina, maakt dat het vinden van de juiste plaats voor ons een stuk makkelijker. Ik verwijder gewoon de moeilijke manieren, levert ons nu dan nog even wat meer werk op maar goed. Op een gegeven moment zal het mogelijk zijn om op de stad te klikken en dat informatie te geven (een variatie op de POI layer. Ik zal proberen het deze week opgang te krijgen, maar ik heb nog veel te doen als dat werkt veranderen we de how-to wel weer. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
