Re: [OSM-talk] OSMXAPI
Would it additionally be feasible to add some sort of limit parameter (a la the MySQL LIMIT parameter) to OSMXAPI calls? That would be useful for writing programs where you don't know exactly what the user might ask for. As a real example, I'd like to limit the return from a web-based POI node search to just 100 nodes. Mike At 06:54 PM 23/07/2008, 80n wrote: >I've just implemented a change to OSMXAPI which will filter out and reject >silly requests (like highway=*). > >The filter uses a combination of bbox size and count of matching elements to >determine whether or not to process the request. > >At this stage it is a bit experimental and there is scope for fine tuning what >it accepts and rejects. > >If you find that it is rejecting a request that you think is reasonable then >please let me know. I want to find the point where all reasonable requests >are still accepted but silly or badly formed ones are rejected. > >This should make a big difference to the throughput as previously osmxapi >would easily get bogged down by someone requesting the whole planet and then >retrying two or three times when they don't get a response within 10 seconds. > >80n ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Collapsed names
in the italian mailing list we are facing new (and some old) users arguing should be better to enter in the name tag the collapsed form of the name. I'm trying to persuade this people this is the wrong way 'cause don't exist any way to explode names collapsed. I'm proposing to add 2 extension to the name tag to mark which part of the name could be collapsed or hidden in the same moment you could give a priority e.g. exploded form: Viale don Luigi Sturzo first: V.le don Luigi Sturzo 2nd: V.le Luigi Sturzo 3rd: V.le L. Sturzo so name=Viale don Luigi Sturzo name:collapsable=1;3 name=hide=2 so... you are adding tips usefull to renderes about which part of the name collapse or hide but it's not a mandatory collapsation If you are the coder of a renderer you can chose to hide befor collapse or collapse before hide.. Let me know it make sense or not.. Edoardo -- Edoardo Marascalchi ICT Consultant Tel +39.347.008.00.02 website: http://www.edoardomarascalchi.it skype: My status ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
On 25/07/2008 10:56, Edoardo Marascalchi wrote: > in the italian mailing list we are facing new (and some old) users > arguing should be better to enter in the name tag the collapsed form of > the name. > > I'm trying to persuade this people this is the wrong way 'cause don't > exist any way to explode names collapsed. > > I'm proposing to add 2 extension to the name tag to mark which part of > the name could be collapsed or hidden > in the same moment you could give a priority > > e.g. > > exploded form: Viale don Luigi Sturzo > first: V.le don Luigi Sturzo > 2nd: V.le Luigi Sturzo > 3rd: V.le L. Sturzo > > so > name=Viale don Luigi Sturzo > name:collapsable=1;3 > name=hide=2 > > so... > you are adding tips usefull to renderes about which part of the name > collapse or hide but it's not a mandatory collapsation > If you are the coder of a renderer you can chose to hide befor collapse > or collapse before hide.. > > Let me know it make sense or not.. Edoardo I'm collecting a list of contractions and abbreviations, at http://wiki.openstreetmap.org/index.php/Name_finder:Abbreviations If you can add a section for Italian, that would be great. In due course, these will be used in the name finder so that when someone searches for e.g. "V.le Luigi Sturzo" they will find "Viale don Luigi Sturzo" even though it isn't spelled like that anywhere in the tags. This already works for lots of contractions in English, American(!), German, French and a few others, but there's no Italian input so far. If this list were available as XML or some such, I guess renderers could use it to shorten the names if necessary to fit on the map or simply for stylistic reasons. I think manually adding variations would then largely be unnecessary. Where there is a radically different form (let's say hypothetically "Viale don Luigi Sturzo" could also be expressed as "Plaza Sturzo", so it's not really a contraction), you can already use alt_name="Plaza Sturzo" and name finder will pick it up. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
EdoM, > I'm proposing to add 2 extension to the name tag to mark which part of > the name could be collapsed or hidden > in the same moment you could give a priority Your idea of referecing parts of the name tag with numbers is error- prone because (a) people will not always agree on how names are split in parts (is "Baah blaah-blah blah" a three-part name or a four-part name?), and (b) people will change the name and forget to change the extra attributes because they're not clear about what they mean. If you want to have shortened names in the database, then I would put them in there explicitly, like so: name=Viale don Luigi Sturzo name_short_1=V.le don Luigi Storzo name_short_2=V.le Luigi Sturzo name_short_3=V.le L.Sturzo But generally I believe the renderer should just have proper rules about shortening and use them - so you would only employ above scheme for exceptions that the renderer cannot derive automatically. In my eyes it would be a great idea to develop some not-too-complex XML document where such rules can be formalized. We could then have our renderers read that document and use it, and host it on the Wiki so everyone can put in their collapsation rules for their local language. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
Perhaps this would work: name=Viale don Luigi Sturzo short_name=V.le don Luigi Sturzo very_short_name=V.le L. Sturzo If short_name and very_short_name are present then use them, otherwise the renderers can use whatever automated algorithm they like. This would handle with all the corner cases that will never be fully abbreviated automatically. For example: name='s-Hertogenbosch short_name=Den Bosch 80n On Fri, Jul 25, 2008 at 10:56 AM, Edoardo Marascalchi < [EMAIL PROTECTED]> wrote: > in the italian mailing list we are facing new (and some old) users > arguing should be better to enter in the name tag the collapsed form of > the name. > > I'm trying to persuade this people this is the wrong way 'cause don't > exist any way to explode names collapsed. > > I'm proposing to add 2 extension to the name tag to mark which part of > the name could be collapsed or hidden > in the same moment you could give a priority > > e.g. > > exploded form: Viale don Luigi Sturzo > first: V.le don Luigi Sturzo > 2nd: V.le Luigi Sturzo > 3rd: V.le L. Sturzo > > so > name=Viale don Luigi Sturzo > name:collapsable=1;3 > name=hide=2 > > so... > you are adding tips usefull to renderes about which part of the name > collapse or hide but it's not a mandatory collapsation > If you are the coder of a renderer you can chose to hide befor collapse > or collapse before hide.. > > Let me know it make sense or not.. > > Edoardo > > -- > Edoardo Marascalchi > ICT Consultant > > Tel +39.347.008.00.02 > website: http://www.edoardomarascalchi.it > skype: My status > > > ___ > 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] Collapsed names
On 25/07/2008 11:11, Frederik Ramm wrote: > In my eyes it would be a great idea to develop some not-too-complex > XML document where such rules can be formalized. We could then have > our renderers read that document and use it, and host it on the Wiki > so everyone can put in their collapsation rules for their local > language. GMTA It would be nice if an XML file were easily editable and could be displayed nicely in the wiki... funny, I seem to have deja vu here re Map Features. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Namefinder priorities
To avoid enormous numbers of confusing duplicates, the Name finder has an algorithm which says "items of the same kind with the same name within 3km of each other are only represented once". On the whole, this works very well, but it sometimes causes problems with common names, for example many "Main Street" and "High Street" in closely spaced neighbouring villages. I tend to put "High Street (Cheveley)" for example which disambiguates and I think is often helpful visually on the map. Also, it is often the case that a street will have one or more spurs off it with the same name. Then, the spur may be the one the name finder chooses rather than the main body of the street. (I sometimes put "Blah Street (spur)" as the name, but would prefer not to.) I am wondering whether it would be useful to have a simple tag such as search=true which would override the name finder's algorithm, giving preference to that object, and always including it in the index. So if there are two nearby instances of High Street both tagged search=true they would both get included, and if the main part of Blah Street is tagged search=true it would be the one taken in preference to any other. I've thought about not tagging for the rendering (and name finder is a kind of renderer), but there isn't a simple algorithmic solution. While it might be possible to do some analysis of connections to try to determine when two things are part of the same, this is a very expensive calculation in what is already a slow process, which makes practicality difficult, though not impossible; but in the case of indicating the preferred branch, I think this is a matter of judgement and can't be done algorithmically from the information that's already there (I could do some guesses based on length of number of nodes perhaps, but it would always be heuristic). Doing that might be useful anyway, but I don't think it will provide a perfect solution in all cases. Thoughts? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Namefinder priorities
On Jul 25, 2008, at 13:13, David Earl wrote: > I've thought about not tagging for the rendering (and name finder is a > kind of renderer), but there isn't a simple algorithmic solution. > While > it might be possible to do some analysis of connections to try to > determine when two things are part of the same, this is a very > expensive > calculation in what is already a slow process, which makes > practicality > difficult, though not impossible; but in the case of indicating the > preferred branch, I think this is a matter of judgement and can't be > done algorithmically from the information that's already there (I > could > do some guesses based on length of number of nodes perhaps, but it > would > always be heuristic). Doing that might be useful anyway, but I don't > think it will provide a perfect solution in all cases. An alternative to search=yes that might be more generally useful is to group parts of a street into a relation (see http://wiki.openstreetmap.org/index.php?title=Relation:street) . That would be an object you could point to. It would also be possible to mark spurs with role=spur if that would help. Cheers Robert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
On Friday 25 July 2008 12:11:48 Frederik Ramm wrote: > EdoM, > > > I'm proposing to add 2 extension to the name tag to mark which part of > > the name could be collapsed or hidden > > in the same moment you could give a priority > > Your idea of referecing parts of the name tag with numbers is error- > prone because (a) people will not always agree on how names are split > in parts (is "Baah blaah-blah blah" a three-part name or a four-part > name?), and (b) people will change the name and forget to change the > extra attributes because they're not clear about what they mean. > > If you want to have shortened names in the database, then I would put > them in there explicitly, like so: > > name=Viale don Luigi Sturzo > name_short_1=V.le don Luigi Storzo > name_short_2=V.le Luigi Sturzo > name_short_3=V.le L.Sturzo perhaps better: name_short=V.le don Luigi Storzo;V.le Luigi Sturzo;V.le L.Sturzo or? > But generally I believe the renderer should just have proper rules > about shortening and use them - so you would only employ above scheme > for exceptions that the renderer cannot derive automatically. Agreed! I brought up exactly the same question a couple of months ago, and got convinced that that would make the most sense. Not that I've seen any renderers pick it up, though... :-P -Inge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Namefinder priorities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Vollmert wrote: | On Jul 25, 2008, at 13:13, David Earl wrote: |> I've thought about not tagging for the rendering (and name finder is a |> kind of renderer), but there isn't a simple algorithmic solution. I always thought that "Not tagging for rendering" means "Don't tag a wide river as a motorway to make it a large blue line on the map", or, as someone did recently "Don't tag roads under construction as tunnels to make them dashed lines on the map" IMHO, it doesn't mean "Don't invent a tag that is useful for renderers". That's OK (although it's much better to use existing tags and/or try to ensure new tags are useful in other situations in future). Having said all that, in this case: | An alternative to search=yes that might be more generally useful is to | group parts of a street into a relation (see http://wiki.openstreetmap.org/index.php?title=Relation:street) | . That would be an object you could point to. It would also be | possible to mark spurs with role=spur if that would help. That is a much better idea - if a way is part of a relationship that supplies a name, use the relationship's name, not the way's. Personally, if I search for M25, I probably want to see this: http://www.openstreetmap.org/?lat=51.486&lon=-0.087&zoom=10 (the whole M25) Rather than 100 results that look like these: http://www.openstreetmap.org/?lat=51.53392&lon=0.27965&zoom=17 http://www.openstreetmap.org/?lat=51.34412&lon=0.15669&zoom=17 http://www.openstreetmap.org/?lat=51.68061&lon=0.00565&zoom=16 which is the kind of thing you get now. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJ7jgACgkQz+aYVHdncI2DLACg5iO43wdK1x5XgCjwnu6askrv p9EAoMyYJQJIhdMWHCETgzPU/gYi+IyS =6Y29 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] House numbers... One more suggestion
Hello, I added one suggestion to the "House Numbers" page. It's the eighth one. http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers I really think we must solve this issue quickly, for two reasons: - it will make the map really more attractive. We must have a map at the same level as our "competitors". - it will save a lot of time: entering street names and THEN numbers doubles the number of visits, and so on. So please add comments, ask for more information if you want. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
Hi, > I added one suggestion to the "House Numbers" page. It's the eighth one. > http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers I find that very confusing. I'm using the "Karlsruhe Schema" http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers and if you want to start mapping house numbers withtout endless discussions, I recommend you just do the same. The house numbers will even show up on Osmarender z17, albeit in a sort of "debug" view which will have to be improved. The Karlsruhe Schema has multiple facets. We assume that in the long run (long! run!) we will have all building outlines in our database anyway, so each building will simply be tagged with its house number and that's that. Until that happens, the Karlsruhe schema lets you place individual nodes for individual house numbers, or use interpolation between nodes placed at street corners. These interpolation rules are explicitly modeled as a new way connecting the nodes, which may look a but unusual at first but (a) it's going to go away once editors learn how to "dim" these lines and (b) it's going to go away once we have each house separate. Your suggestion of using "house_number:W_L" and such is asking for trouble IMHO. > - it will save a lot of time: entering street names and THEN numbers doubles > the number of visits, and so on. This is not true, at least not generally. The initial mapping is often done by car or bike where you cannot be expected to record house numbers, even if you only want to record those at an intersection. House numbers typically require visiting the area on foot or at least, if by bike, then with a lot of extra time. Also, house numbers may be entered by people who live in the area and don't even have a GPS. So no need to rush. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
Frederik Ramm wrote: >Sent: 25 July 2008 6:13 PM >To: Charlie Echo >Cc: talk >Subject: Re: [OSM-talk] House numbers... One more suggestion > >Hi, > >> I added one suggestion to the "House Numbers" page. It's the eighth one. >> http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers > >I find that very confusing. > >I'm using the "Karlsruhe Schema" >http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers >and if you want to start mapping house numbers withtout endless >discussions, I recommend you just do the same. The house numbers will >even show up on Osmarender z17, albeit in a sort of "debug" view which >will have to be improved. > >The Karlsruhe Schema has multiple facets. We assume that in the long >run (long! run!) we will have all building outlines in our database >anyway, so each building will simply be tagged with its house number >and that's that. Until that happens, the Karlsruhe schema lets you >place individual nodes for individual house numbers, or use >interpolation between nodes placed at street corners. These >interpolation rules are explicitly modeled as a new way connecting the >nodes, which may look a but unusual at first but (a) it's going to go >away once editors learn how to "dim" these lines and (b) it's going to >go away once we have each house separate. > >Your suggestion of using "house_number:W_L" and such is asking for >trouble IMHO. > >> - it will save a lot of time: entering street names and THEN numbers >doubles the number of visits, and so on. > >This is not true, at least not generally. The initial mapping is often >done by car or bike where you cannot be expected to record house >numbers, even if you only want to record those at an intersection. >House numbers typically require visiting the area on foot or at least, >if by bike, then with a lot of extra time. Also, house numbers may >be entered by people who live in the area and don't even have a GPS. > >So no need to rush. > +1 to this approach generally. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] The return of the coastline checker
On Tue, Jul 22, 2008 at 2:34 AM, Rob Reid <[EMAIL PROTECTED]> wrote: > Has it stopped again, status shows last update was the 18th. Hmm, yes. It has been disabled due to excessive memory usage. The process of converting OSM ways into shapes took up too much memory on hypercube... I thought I could fix it to use a lot less memory but I was wrong and I havn't had any real bright ideas yet... Nor a lot of time either. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
On Fri, Jul 25, 2008 at 7:12 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > I find that very confusing. > > I'm using the "Karlsruhe Schema" > http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers Ok, I've looked at this and I'm missing the case where a building has a number of street numbers attached to it. An example: for most of the street there'd be just houses with numbers, the easy case: they'd be 1-31 (odd). Then there'd be a block of flats with say: 33-279 (odd), followed by some more houses: 281-299 (odd). I suppose you could cover the building with linear features to approximate the individual apartments, but I suppose the suggestion would be a simple linear between the road and the building with just the start and end number, right? Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
On Fri, Jul 25, 2008 at 7:12 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > I'm using the "Karlsruhe Schema" > These interpolation rules are explicitly modeled as a new way connecting > the > nodes, which may look a but unusual at first but (a) it's going to go > away once editors learn how to "dim" these lines and (b) it's going to > go away once we have each house separate. > > I really have a problem with this 'way' linking address nodes in the Karlsruhe schema. We know that the relation has been created for that. This 'way' is just here because some people do not know (or don't want to know) how to use relations in the editors. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] House numbers... One more suggestion
Hi, > I really have a problem with this 'way' linking address nodes in the > Karlsruhe schema. We know that the relation has been created for that. > This 'way' is just here because some people do not know (or don't want > to know) how to use relations in the editors. Then use a relation instead. It's a free world ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
Frederik Ramm wrote: > > If you want to have shortened names in the database, then I would put > them in there explicitly, like so: > > name=Viale don Luigi Sturzo > name_short_1=V.le don Luigi Storzo > name_short_2=V.le Luigi Sturzo > name_short_3=V.le L.Sturzo > > But generally I believe the renderer should just have proper rules > about shortening and use them - so you would only employ above scheme > for exceptions that the renderer cannot derive automatically. Not sure whether you can find an algorithm that actually manages to find the correct short versions for all possible languages and places. You can't just shorten, say, Viale to V.le on a general basis as it may appear as a main part of a name. The shortening is only possibly if (a) you are in Italy or the Italian part of Switzerland and (b) it appears as the first word. It gets even trickier, if you want to shorten or even leave out first or middle names like Luigi in the above example. Is the first of two names a first name or rather the first part of a double name? An alternative approach would be some sort of name expression. Something like name_expr=(Viale|V.le) [don] [(Luigi|L[.])] Sturzo This also covers odd cases like my own street which is either a Via or a Viale, depending on whom you ask. Instead of having lots of alternative or shorter names, it becomes simply name_expre=(Via|Viale) [Battista] Foletti (I haven't seen viale shortened to V.le just yet). The drawback is that these expressions tend to get out of hand and that you will have to escape brackets, parentheses and vertical bars. But if the parens are replaced by braces, this should be reasonably safe. And I don't think, this needs anything more complex than just alternatives and optionality. If a canonical name exists, it can go into the name tag just like today. Regards, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
On 25/07/2008 22:11, Martin Hoffmann wrote: > Frederik Ramm wrote: >> If you want to have shortened names in the database, then I would put >> them in there explicitly, like so: >> >> name=Viale don Luigi Sturzo >> name_short_1=V.le don Luigi Storzo >> name_short_2=V.le Luigi Sturzo >> name_short_3=V.le L.Sturzo >> >> But generally I believe the renderer should just have proper rules >> about shortening and use them - so you would only employ above scheme >> for exceptions that the renderer cannot derive automatically. > > Not sure whether you can find an algorithm that actually manages to find > the correct short versions for all possible languages and places. You > can't just shorten, say, Viale to V.le on a general basis as it may > appear as a main part of a name. The shortening is only possibly if (a) > you are in Italy or the Italian part of Switzerland and (b) it appears > as the first word. It gets even trickier, if you want to shorten or even > leave out first or middle names like Luigi in the above example. Is the > first of two names a first name or rather the first part of a double > name? [snip] There's two separate cases (1) recognizing that variations are equivalent so that searching works. I think I've demonstrated that that can work pretty well, without needing to know the language - because 9a) it doesn't matter if you get the odd extra hit on occasion, (bn) searches can be context sensitive, and (c) you don't get to see and people don't search for the silly variations that the database sometimes holds because of different languages. (2) Drawing shorter variants when rendering. You only really need one variation there, probably the shortest one. In principle it ought to be possible to determine the country an object is in, even though it is quite hard at present. I think a lot of things would benefit from this ability: nationally-styled rendering rules, deciding which way roundabouts go, name renderings, validation, improved searching context etc. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] GPS receiver orientation
Random question: does the orientation of a GPS receiver make any difference? If I hold my BGT-11 vertically, will it find it harder to get and keep a lock than if I hold it horizontally? Also, does it make it slower to get a lock if I walk along while it's trying? I don't know the chipset, if that makes a difference - I think it may be SirfStar II. The wiki would know (I'm offline as I type). Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Slippy map not working in Firefox
Frederik Ramm wrote: > No problems with firefox 1.04 under Debian ;-) Anyone still using Firefox 1 or 1.5, please upgrade. These versions are old enough to have known serious security issues. This has been a public service announcement :-) Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Collapsed names
David Earl wrote: > > There's two separate cases > > (1) recognizing that variations are equivalent so that searching works. > I think I've demonstrated that that can work pretty well, without > needing to know the language - because 9a) it doesn't matter if you get > the odd extra hit on occasion, (bn) searches can be context sensitive, > and (c) you don't get to see and people don't search for the silly > variations that the database sometimes holds because of different > languages. True. In this context, being overly "helpful" is a good thing. You might also want to look for variations of the name, say, if someone types "Holland Road" you may also look for "Holland Street" if no result can be found for the former. > (2) Drawing shorter variants when rendering. You only really need one > variation there, probably the shortest one. Not sure I agree here. You want to put as much of the name into the rendered map as space allows. Keeping the first names of people or at least only shortening them to an initial may be a good thing because they appear up front. From a name like "Serafino Balestra" a foreigner wouldn't necessarly guess that this refers to a person and "Serafino" can be dropped. > In principle it ought to be > possible to determine the country an object is in, even though it is > quite hard at present. I think a lot of things would benefit from this > ability: nationally-styled rendering rules, deciding which way > roundabouts go, name renderings, validation, improved searching context > etc. Definitely. Regards, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
HOTLIST-moreDICE Tivoli Administrator/ Chicago, IL/ 6 Months
*Tivoli Administrator.* *Chicago, IL* *Duration: 6 Months* *Rate: Open * * 1.Provide day to day administration of Tivoli infrastructure support for TEC and ITM 5.1. 2. Design and deploy custom monitoring solutions for servers, log file adaptors and applications utilizing ITM 5.1 resource models. Solve technical and operational tools issues. 3. Identifies issues that impact service provision and may make recommendations to management. 4. Prepares and submits project status and other reports to management. 5. Plan, organize and manage ITM and TEC testing. 6. May work with other departments or may provide technical assistance to others within the department. 7. Performs other essential duties as assigned. Knowledge, Skills and Abilities 1. Needs to have a strong working knowledge of UNIX (AIX & Solaris) and UNIX Shell and Perl Scripting. 2. Strong knowledge of the functions performed by the business unit with developing knowledge of the monitoring industry. 3. Excellent organizational and analytical skills including ability to prioritize and coordinate multiple projects. 4. Strong analytical and problem solving skills. 5. Strong client and team interpersonal skills with the ability to effectively interact with all internal and external business partners. 6. Effective verbal and written communication skills, with the ability to convey technical and business information in a clear, concise and effective manner. 7. Ability to exercise professional judgment and assume responsibility for decisions which have an impact on people, costs and quality of service. 8. Ability to work independently as well as in a team environment. 9. Knowledge of Microsoft Office suite and the ability to learn and utilize other business related software systems including database and operating systems. 10. Must have excellent communication skills and work well in a team environment. * * -- Thanks and Regards Ramesh Kumar Vayu Inc Phone No : 330-931-4649 Fax No : 330-266-7336 Email : [EMAIL PROTECTED] Web : www.vayuvision.com Yahoo : Recruitinginpeace * --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "HOTLIST-moreDICE" group. To post to this group, send email to HOTLIST-moreDICE@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/HOTLIST-moreDICE?hl=en -~--~~~~--~~--~--~---
