Re: [OSM-dev] likenesses
Hi, Eugene Alvin Villar wrote: Inasmuch as the underlying concepts are identical (more or less), I don't like the idea that we can use different key name or values to represent those concepts. Thing is, the underlying concepts will very often be more or less identical but never really. At the risk of expanding this into the vapourware realm, we have a very similar problem with hierarchic tagging which we sometimes try to solve by chain-tagging like in this fictional example: natural=water water=lake lake=freshwater We do this so that a renderer that only knows how to render water areas can work with this; and a renderer capable of distinguishing freshwater mountain reservoirs from quarry ponds (oops... not natural, is it?) also has the necessary information. Now if we introduce a likeness layer as SteveC suggested, that may also serve as a general what is what structure. The fact that a quarry pond is basically a lake and a lake is basically a body of water would no longer have to be explicitly tagged; it would be sufficient to tag man_made=quarry_pond and any renderer just interested in bodies of water could know that from the likeness layer. This would make the likeness layer a central point of tagging, and free edit access to the likeness layer would become crucial for everyone, but at the same time it would allow anybody to invent the most crazy tags and say oh well, if the renderer does not understand llwerewta=uwerwssc then it may treat this as an ordinary body of water. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlach has wrong preset
On Sun, 27 Sep 2009 14:25:29 +, Valent Turkovic wrote: Hi, I have noticed that Potlach assigns wrong tags for dirt dirt track. When you select dirt track potlach adds highway=track and surface=dirt tags. That wouldn't be an issue if the icon beside it wouldn't be man walking. There should be a car icon instead of man walking or the tag should be highway=path surface=dirt Am I missing something? Do you see this as a bug? Should I report it? How? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 SteveC st...@asklater.com I think it is an interesting idea. It would make some people happy about tag proliferation and gradually it has the possibility of fixing things up. The debate on orchard, plantage, farmland could be partially be solved by this mechanism, while allowing application developers to perform substitution for whatever need they have. I agree that we need to look at the keys first. Values will be more controversial on some aspects :) Emilie Laffray ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlach has wrong preset
valentt wrote: Hi, I have noticed that Potlach assigns wrong tags for dirt dirt track. When you select dirt track potlach adds highway=track and surface=dirt tags. That wouldn't be an issue if the icon beside it wouldn't be man walking. There should be a car icon instead of man walking or the tag should be highway=path surface=dirt Am I missing something? highway=track does not imply a road for vehicles. If you want to do so you should add some access tags. cheers Richard -- View this message in context: http://www.nabble.com/potlach-has-wrong-preset-tp25634190p25695755.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 3:25 AM, SteveC st...@asklater.com wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. Closest I got was the osmosis tagtransform plugin [1]. I made that because people keep insisting on tagging things like highway=path;bicycle=yes|designated, which is essentially like a highway=cycleway and we want those rendered on the cycle map. Now for various reasons, mostly due to laziness, version mismatches, and not being entirely sure about what the different path combinations mean, this has never been deployed on the cycle map for real, but anyway. What I was originally thinking was that what would be nice (and therefore almost certain to be never developed) would be a proper tagging app on the OSM website which let people describe their tagging schemes. Part of that would then be how to get from one scheme to another. In thinking how you might do that some of the weird and wonderful ways that schemes differ come to mind and tagtransform was born. Back to the likenesses, saying an autobahn is like a motorway makes sense, is a good start, but very limited. One of the first problems you hit is what like actually means. In the UK a lot of footpaths look a lot like a lot of bridleways. So therefore highway=footway is like highway=bridleway, one allows horses but the other doesn't otherwise they're mostly the same. But a lot of foot paths are like cycle paths, which are a lot like tracks which are a lot like service roads which are a lot like unclassified roads. Anyway it turns out that just about all roads and paths are transitively like each other which is a little confusing and not a very useful result. With the likenesses XML you could sort this out with overlapping likeness groups but it quickly becomes a problem for renderers if they're trying to find things which are like a footpath, and things which are like a cycle path, because lots of things are like both and you don't know why. So the way in which something is alike is actually very important. What may be a better idea is object hierarchies -- ie: is-a links or mediawiki-like categories. This way you end up doing things the other way round... feature tag k=highway v=motorway/ is-aroad/is-a is-amajor-road/is-a is-abiggest-roads-we've-got/is-a is-aroad-with-speedlimit/is-a is-aroad-which-meets-uk-reg-blah15/is-a is-aroad-which-meets-eu-reg-blah01/is-a /feature feature tag k=insert german for road or whatever v=autobahn/ is-aroad/is-a is-amajor-road/is-a is-abiggest-roads-we've-got/is-a is-aroad-which-meets-de-reg-blah97/is-a is-aroad-which-meets-eu-reg-blah01/is-a /feature (that's very flat, there's no reason you couldn't actually structure it a bit by introducing the categories as objects with categories, and those is-a parts could easily be OSM tags specifying actual speedlimits etc with the expectation these represent the defaults) So now the renderer can just go for the biggest-roads-we've-got category, and render anything that matches. And surprise surprise it ends up looking a heck of a lot like an editor presets description file [2]. And that fact is interesting because of the question: why didn't we just tag all the motorways like that in the first place? Screw highway=motorway, just add road=yes;major_road=yes;biggest_road_we_have=yes... I can think of a couple of reasons. - we're all lazy and don't want to type it -- editor presets can negate that one - the german government decides to impose a speedlimit so we immediately get to change the autobahn definition rather than retag all the objects using an evil bot One of the big questions is whether all of this would make life easier or harder for the renderers -- it would definitely raise the tech start bar. Dave [1] http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform [2] See the potlatch 2 map-features.xml http://trac.openstreetmap.org/browser/applications/editors/potlatch2/resources/map_features.xml -- but there you're limited to one category because it's more for menu structure than proper categorisation. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 3:25 AM, SteveC st...@asklater.com wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. We have already, it's been made and engineered and everything. Don't mistake endless unproductive waffle on the mailing lists as evidence that a problem hasn't been solved - it's just people who aren't capable pleading to the gods to come and save them from themselves. http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
SteveC wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. Wow, lots of issues here. And since I'm not a socialist moral relativist ...I am, almost, then I get a head-start on this one. :p I'm generally with Eugene in agreeing that the words don't mean anything. Perhaps the best example is highway=trunk. That was invented over here (*waves at Andy R*) but we don't use it for UK trunk roads. We use it for UK primary routes. Non-primary routes, we tag as, er, highway=primary. This can only increase as editors increasingly abstract tagging away from the keys and values. I've even seem some screenshots of some upcoming editor or other with these lovely clickable icons with little cars on them - don't know if you've seen that one? So motorway or autobahn - meh. It's just words. But, that aside: yes, we should do it. We have all sorts of 'implied' tags. highway=motorway implies foot=no and bicycle=no. junction=roundabout implies oneway=yes. And yes, anything (well, except name maybe) =true implies =yes. We also have implication by area. highway=motorway on a road in the UK implies maxspeed=70mph, whereas in France, it implies maxspeed=110. Implying things is good, because we optimise for the mapper, not the client. It does mean the client needs to figure all this out. I've long said we should (sorry) have standard libraries talking to some sort of dictionary with all this in: as a first step to a dictionary, the other year I started (not machine-readable) http://wiki.openstreetmap.org/wiki/Key:highway#International_equivalence which has been taken up by a bunch of other people and is, really, the only sane description of highway types we have. But it's not machine readable. This looks like the same kind of idea but machine readable, so, yay. Apart from the XML bit. ;) cheers Richard -- View this message in context: http://www.nabble.com/likenesses-tp25692251p25696173.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
Dave Stubbs wrote: One of the big questions is whether all of this would make life easier or harder for the renderers -- it would definitely raise the tech start bar. Standard libraries ftw. People's unwillingness to do any form of pre-processing on an increasingly varied OSM dataset never ceases to amaze me. One bit of code translated into Perl/Ruby/AS3/whatever the cool kids are using(tm) sorts it all. cheers Richard -- View this message in context: http://www.nabble.com/likenesses-tp25692251p25696196.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 11:16 AM, Richard Fairhurst rich...@systemed.net wrote: Dave Stubbs wrote: One of the big questions is whether all of this would make life easier or harder for the renderers -- it would definitely raise the tech start bar. Standard libraries ftw. People's unwillingness to do any form of pre-processing on an increasingly varied OSM dataset never ceases to amaze me. One bit of code translated into Perl/Ruby/AS3/whatever the cool kids are using(tm) sorts it all. Or merely publishing their TagTransform rulesets, and then the most useful ones will rise to predominance, perhaps with different ones for different specialisms. Especially since nearly everyone uses osmosis at some point in their toolchain. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 11:33 AM, Jonathan Bennett openstreet...@jonno.cix.co.uk wrote: Andy Allan wrote: We have already, it's been made and engineered and everything. Don't mistake endless unproductive waffle on the mailing lists as evidence that a problem hasn't been solved - it's just people who aren't capable pleading to the gods to come and save them from themselves. http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform That's a way of dealing with the problem at a data level, but it doesn't deal with it at a people level. To use TagTransform you either have to accept the presets (which could be out of date) or come up with your own transformations, which could take a lot of research and still not reflect what mappers are doing. If I understand what Steve is talking about, he wants a way for mappers to *document* what they think the equivalences are between tags. So that would be the source material you'd plug into TagTransform. For what it's worth, I think that's the wrong way of going about it. I think multiple descriptions of the same tag in different locales is the way to go. +1 there's clearly two places to do this transform; in the editor (i.e: presets) and as a filter before the app which consumes the data (i.e: tagtransform). the two places reflect very different types of transform, though. translations in the editor are clearly for the benefit of the user, who might prefer to see straßen-typ=autobahn rather than highway=motorway. but what really distinguishes an autobahn from a motorway? i assume there's several differences in the laws regarding them, but the primary difference is; all the motorways are in the UK and all the autobahns are in Germany. so it would be inappropriate to tag anything straßen-typ=autobahn in the UK - even if you prefer to have the UI in German while you're editing the UK. isn't it easier to let the editor handle language and locale-specific presentation of the tag, but leave the data more-or-less consistent? translations in the consumer are there (usually) to reduce the vocabulary of OSM down to things that the app can handle. a simple example might be that, for all their differences, it makes some sense to render residential and unclassified roads as the same minor road type. this, also, is probably locale-dependent. there have been discussions on talk@ before about whether footpaths are also permissive cycleways in various countries and what the default implication of higway=footway should be. (disclaimer: i only dimly remember this, so i may have got it totally wrong). again, it makes sense to have a fairly universal set of tags in the data with a locale-specific translation. this translation will also be domain-specific; only a cycle-specific renderer, or a cycle routing engine would care about the distinction in the previous example. while i'm all in favour of a library of tag transforms and editor presets, i'm against having any fixed, defined set of tag equivalences. that seems to me like the beginnings of an ontology. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 David Earl da...@frankieandshadow.com: On 01/10/2009 03:25, SteveC wrote: I want to revive a very old idea - tag equivalences. I would like to go further than Steve proposes, but I understand it is a hard sell to the anarchist wing of OSM while being welcome to the conformist wing. But I really think what I outline below treads a middle way. I'm absolutely not proposing to restrict anyone's freedom to add new tags or values. I don't see what your persauation has to do with anything, I'm looking at this from a practical point of view, it's easier to do translations in the editor and then have the editor do the processing into a pre-defined set of tags, rather than having 1000s of servers doing the translations every time they have to parse the data, that's crazy and complete waste of CPU time. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On 01/10/2009 12:54, John Smith wrote: 2009/10/1 David Earl da...@frankieandshadow.com: On 01/10/2009 03:25, SteveC wrote: I want to revive a very old idea - tag equivalences. I would like to go further than Steve proposes, but I understand it is a hard sell to the anarchist wing of OSM while being welcome to the conformist wing. But I really think what I outline below treads a middle way. I'm absolutely not proposing to restrict anyone's freedom to add new tags or values. I don't see what your persauation has to do with anything, I was only heading off the inevitable people should be absolutely free to do anything they want type comments that have always been among the responses to suggestions like this. I'm looking at this from a practical point of view, it's easier to do translations in the editor and then have the editor do the processing into a pre-defined set of tags, rather than having 1000s of servers doing the translations every time they have to parse the data, that's crazy and complete waste of CPU time. I think you missed the point (and also I was just responding to Steve's original message). In my suggestion the translation is done once and stored with the tag definition. The editor simply reads and presents it. Currently every editor has to have its own translation, and chances are also that they will be different. They can also offer common translated help beyond just the word that is used for the tag, and everyone gets updated when that changes. Keeping multiple, probably different, descriptions and translations across all the programs that use OSM is the thing that seems crazy to me. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 David Earl da...@frankieandshadow.com: Keeping multiple, probably different, descriptions and translations across all the programs that use OSM is the thing that seems crazy to me. Sorry, misunderstood what you were suggesting, I agree 100% I've done something similar in the past when we want to have consistency between apps on multiple phone platforms, we store a JSON encoded array on a work server, the apps download this file and you get consistency across all platforms, this is the same thing, except editors :) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
El Jueves, 1 de Octubre de 2009, SteveC escribió: Thoughts? Likenesses -1; implications +1. e.g.: highway=autobahn implies highway=motorway highway=motorway implies oneway=yes highway=motorway implies highway=road Basically it's just the same idea, but by using the word imply, it suddenly becomes a strictly logical proposition. I personally feel that SteveC's proposal of likenesses (A is like B) can be misleading, whereas implications (A implies B) are univocal. Likenesses are just aliases, implications add more meaning to the tags. So, osm2pgsql (or whatever) should unfold everything, unless there are existing values that contradict (e.g. highway=motorway, oneway=no). (I haven't read the entire thread, but I think some other people already agree to this) Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es http://ivan.sanchezortega.es MSN:i_eat_s_p_a_m_for_breakf...@hotmail.com Jabber:ivansanc...@jabber.org ; ivansanc...@kdetalk.net IRC: ivansanchez @ OFTC freenode signature.asc Description: This is a digitally signed message part. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 Dave Stubbs osm.l...@randomjunk.co.uk: That argument is bogus. It's much easier to do the translations on a couple of servers rather than make the 100,000's editors more complicated so that they use more laptop battery and make all the mappers have to go home early. Well JOSM is already doing it, so it can't be that bogus... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 1:33 PM, John Smith deltafoxtrot...@gmail.com wrote: 2009/10/1 Dave Stubbs osm.l...@randomjunk.co.uk: That argument is bogus. It's much easier to do the translations on a couple of servers rather than make the 100,000's editors more complicated so that they use more laptop battery and make all the mappers have to go home early. Well JOSM is already doing it, so it can't be that bogus... Oh yes, selective quoting is also a classic. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The OpenStreetMap website is now translatable at Translatewiki
On Wed, Sep 23, 2009 at 11:52 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: I've now fixed Potlatch up so that it can be Translated on Translatewiki. Now it just needs to be imported into Translatewiki. I've put up a notice on the OSM wiki so that confused Translators won't use it in the interim: http://wiki.openstreetmap.org/index.php?title=Template:Potlatch/Translationdiff=345246oldid=302899 It's now possible to translate Potlatch at Translatewiki too: http://translatewiki.net/wiki/Translating:OpenStreetMap ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlach has wrong preset
2009/10/1 Richard Fairhurst rich...@systemed.net: valentt wrote: Hi, I have noticed that Potlach assigns wrong tags for dirt dirt track. When you select dirt track potlach adds highway=track and surface=dirt tags. That wouldn't be an issue if the icon beside it wouldn't be man walking. There should be a car icon instead of man walking or the tag should be highway=path surface=dirt Am I missing something? highway=track does not imply a road for vehicles. If you want to do so you should add some access tags. IMHO track does imply a width usable by 4-wheel-vehicles (even if legislation in some parts of the world might not allow use by car). In Germany we are using these for forestal and agricultural ways that are indeed used by vehicles. I agree with valent that a car (or maybe better a tractor) would be better icons than a pedestrian. cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/1 Dave Stubbs osm.l...@randomjunk.co.uk: On Thu, Oct 1, 2009 at 1:33 PM, John Smith deltafoxtrot...@gmail.com wrote: 2009/10/1 Dave Stubbs osm.l...@randomjunk.co.uk: That argument is bogus. It's much easier to do the translations on a couple of servers rather than make the 100,000's editors more complicated so that they use more laptop battery and make all the mappers have to go home early. Well JOSM is already doing it, so it can't be that bogus... Oh yes, selective quoting is also a classic. What was your point then? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Open sou...@dtu
We are a group of students from Delhi Technological University and Head,Open Source Society in the college .We wish to work on OSM as a project with an active participation.Please may you guide us for the same. Regards, Nipun Batra Open Source Society Delhi Technological University India ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
On Thu, Oct 1, 2009 at 06:20, David Earl da...@frankieandshadow.com wrote: On 01/10/2009 03:25, SteveC wrote: I want to revive a very old idea - tag equivalences. I would like to go further than Steve proposes, but I understand it is a hard sell to the anarchist wing of OSM while being welcome to the conformist wing. But I really think what I outline below treads a middle way. I'm absolutely not proposing to restrict anyone's freedom to add new tags or values. I think it would be really helpful to bring together the tag definitions into one place, *in the database and API itself*. I mean a complete schema: the tags, their possible values, their descriptions (in multiple languages), their equivalences both in other languages and synonyms, their related tags (in essence properties of the main descriptive tag, hence oneway=... with highway=...), deprecations and so on. +1 It's possible to have anarchy without chaos. -- David J. Lynch djly...@gmail.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
2009/10/2 David Lynch djly...@gmail.com: On Thu, Oct 1, 2009 at 06:20, David Earl da...@frankieandshadow.com wrote: On 01/10/2009 03:25, SteveC wrote: I want to revive a very old idea - tag equivalences. I would like to go further than Steve proposes, but I understand it is a hard sell to the anarchist wing of OSM while being welcome to the conformist wing. But I really think what I outline below treads a middle way. I'm absolutely not proposing to restrict anyone's freedom to add new tags or values. I think it would be really helpful to bring together the tag definitions into one place, *in the database and API itself*. I mean a complete schema: the tags, their possible values, their descriptions (in multiple languages), their equivalences both in other languages and synonyms, their related tags (in essence properties of the main descriptive tag, hence oneway=... with highway=...), deprecations and so on. +1 It's possible to have anarchy without chaos. This is almost the exact same discussion as the SteveC should decide thread on the main talk list with opposite outcomes ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Open sou...@dtu
Hi there, Well do you mean as coders or as editors? First you should start by reviewing the maps of the places you know. Look up your home town and check if it is ok. If you see something missing, use the editor or josm.openstreetmap.de for fixing it. mike ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlach has wrong preset
Martin Koppenhoefer wrote: Sent: 01 October 2009 2:11 PM To: Richard Fairhurst Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] potlach has wrong preset 2009/10/1 Richard Fairhurst rich...@systemed.net: valentt wrote: Hi, I have noticed that Potlach assigns wrong tags for dirt dirt track. When you select dirt track potlach adds highway=track and surface=dirt tags. That wouldn't be an issue if the icon beside it wouldn't be man walking. There should be a car icon instead of man walking or the tag should be highway=path surface=dirt Am I missing something? highway=track does not imply a road for vehicles. If you want to do so you should add some access tags. IMHO track does imply a width usable by 4-wheel-vehicles (even if legislation in some parts of the world might not allow use by car). In Germany we are using these for forestal and agricultural ways that are indeed used by vehicles. I agree with valent that a car (or maybe better a tractor) would be better icons than a pedestrian. And my rule of thumb is if a tractor uses it it's a track, this is basically the same assumption as a 4x4 off road usage. Otherwise it's something else, normally a footway/path etc if narrower. So, two ruts it's a track. If it's paved I tend to use highway=service. Time to put my tagging preferences on my wiki page perhaps :-) Cheers Andy cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Gosmore not Public Domain anymore?
Hi there, in applications/rendering/gosmore http://trac.openstreetmap.org/browser/applications/rendering/gosmore?rev=17737 [17734:17737] http://trac.openstreetmap.org/log/applications/rendering/gosmore?rev=17737stop_rev=17734 the public domain disclaimer, which used to be the first line in gosmore.cpp, went away. Will gosmore stay PD and, if not, what license will it be licensed under in the future? I've modified the code quite a bit - is there any chance on getting svn access / do you accept changes? Regards, Christian / cmuelle8 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Gosmore patch to rebuild pak
Hi,
gosmore fails to rebuild a pak file since the introduction of FWRITE
macro definition. Reason:
fwrite(buf, elemsize, numelems, pak) returns the number of elems written.
fwrite (idx, fsize, 1, pak) will fail, if there is an empty file, in
this case fsize is 0. fwrite is told to write 1 element of zero size.
FWRITE macro will then exit(1) since fwrite returned that 0 elems were
written - this does not match the intent to write 1 element.
Greetings,
cmuelle8
ps: on my system I also need to disable the setlocale() statement in
gosmore.cpp, else a pak rebuild will only produce garbage. since this
intends to solve problems parsing nmea only, i suggest to _not_
setlocale() when in rebuild mode..
pps: there is many more stuff, e.g. in the nmea parsing, I'd like to
submit myself ;-)
Index: libgosm.cpp
===
--- libgosm.cpp (Revision 17900)
+++ libgosm.cpp (Arbeitskopie)
@@ -1545,8 +1553,8 @@
fflush (groupf[i]);
unsigned *idx = (unsigned *) mmap (NULL, fsize,
PROT_READ | PROT_WRITE, MAP_SHARED,
fileno (groupf[i]), 0);
-qsort (idx, fsize / sizeof (*idx), sizeof (*idx), IdxCmp);
-FWRITE (idx, fsize, 1, pak);
+qsort (idx, fsize / sizeof (*idx), sizeof (*idx), IdxCmp);
+FWRITE (idx, sizeof (*idx), fsize / sizeof (*idx), pak);
#if 0
for (int j = 0; j fsize / (int) sizeof (*idx); j++) {
printf (%.*s\n, strcspn (data + idx[j], \n), data + idx[j]);
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Gosmore patch to rebuild pak
On 01/10/09 20:34, Christian Müller wrote: gosmore fails to rebuild a pak file since the introduction of FWRITE macro definition. Reason: Can you not send these messages to the developer of gosmore rather than spamming the dev list with them? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Quantifying
Hi all - I tried to do a rough analysis (for an article I'm writing) of the composition of an API response by character count. If anyone knows more about this or has opinions or ideas for better (but lightweight) means of quantifying this, i'd love to hear them. I’ve been wondering how much of the data transferred by the OpenStreetMap API is actual geometric data as opposed to timestamp and author data. I ran some rough numbers on a typical API response (in JSON, not XML, though these are relative measurements, so it shouldn’t matter too much). The file I examined is here: dr5ru0.jsonhttp://unterbahn.com/wp-content/uploads/2009/09/dr5ru0.json but my count is by number of characters and I did include formatting. Graph and blog post here: it'd be nice to have comments and answers posted here, so they're archived: http://unterbahn.com/2009/10/composition-of-a-openstreetmap-api-responses/ Thanks! Jeff ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Gosmore patch to rebuild pak
Can you not reply with strong words like 'spamming' on messages like these? It sounds so much nicer to point good intending people to the Trac website [1] and have them create tickets and attach the patches there... [1] http://trac.openstreetmap.org (choose component 'gosmore' when submitting tickets) On Thu, 01 Oct 2009 20:55:39 +0100, Tom Hughes t...@compton.nu wrote: On 01/10/09 20:34, Christian Müller wrote: gosmore fails to rebuild a pak file since the introduction of FWRITE macro definition. Reason: Can you not send these messages to the developer of gosmore rather than spamming the dev list with them? Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] shocking - unsecure password sending!
On Thu, 24 Sep 2009 17:49:43 +0200, Tobias Wendorff wrote: A token gets gets generated on the database server (or transmitted to it) and it gets transmitted to the user via HTTPS. The token will encode the password on the user's side and transmit it in plaintext to the server. The server will encode it using the token. That sounds secure to me and shouldn't slow down any process. Any plans on implementing this feature into JOSM? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] shocking - unsecure password sending!
On Thu, 24 Sep 2009 14:18:17 +0200, Stefan Baebler wrote: There are open tickets about ssl and encrypting passwords: http://trac.openstreetmap.org/ticket/275 http://trac.openstreetmap.org/ticket/106 I see these are 4 years old tickets :( How far is it from realization so that we start using secure login with JOSM? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] shocking - unsecure password sending!
Hi, Valent Turkovic wrote: A token gets gets generated on the database server (or transmitted to it) and it gets transmitted to the user via HTTPS. The token will encode the password on the user's side and transmit it in plaintext to the server. The server will encode it using the token. That sounds secure to me and shouldn't slow down any process. Any plans on implementing this feature into JOSM? The JOSM part of any of this (except perhaps OAuth) is trivial and I'm sure if the server supports some kind of secure authentication then someone will hack that up in JOSM. However as long as the server doesn't do SSL there's not much incentive, and frankly I couldn't care less about my username/password being unencrypted so I will not spend any time either coding the Ruby side of things or convincing the server operators to buy and install SSL certificates. But if this is important to you, then go ahead. Bye Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] my solution for the password-problem
Hi there, sorry, I can't find the original thread about the problem that JOSM transfers passwords unprotected to the server... Perhaps my understanding of security is mistaken, but this is the way, how *I* would do it: 1. Set up two small servers (Atom) in the same network as the database server. 2. One of the servers (A) has access to LAN only, the other (B) acts as a webserver with HTTPS. 3. Whenever a OSM-user wants to upload data, JOSM could send the request get new token to server (B). This would request a new token by server (A) and send it to the database server on LAN and to the user via HTTPS. The token could contain something like an IP and timestamp with expire-time. 4. I think, the passwords are stored in MD5 on the DB-server. JOSM should create a hash of the user's password with MD5 and encrypted it with the received token. 5. When the user wants to log in, the encrypted password gets transmitted to the DB-server. Now, the DB-server reads the MD5-checksum for the username and encrypts it with the token it has got from the token server in LAN. 6. This password would only be active, until it expires or until a new one gets requested. Sounds secure to me and would be easy to setup. Perhaps, it would be okay to run server (A) in a VM... Best regards, Tobias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
