Re: [OSM-dev] OAuth difficulties from node.js client
On 16/07/2020 16:04, Nick Whitelegg wrote: Fiurthermore, if I use curl to send the same data to the endpoint, I also get a 500: curl --data "oauth_consumer_key=EcdM735JygrmO42fzw8SIfbFUMDy1ShVY5bBnefn_nonce=cNvPEgdgjvQWX5FgS56XkyLaMhQNggmh_signature_method=HMAC-SHA1_timestamp=1594910535_version=1.0_callback=http%3A%2F%2Flocalhost%2Fapp%2F_signature=WuYA7G8s4qPCht%2BcF7t7FpTP0ck%3D" https://www.openstreetmap.org/oauth/request_token I'm guessing something's wrong with the signing process. I used the examples given in the oauth-1.0a documentation to generate the parameters. I'm surprised I'm getting a 500 rather than say a 400. No that's normal - it's a bug in the OAuth library really but getting a 500 if the client ID is invalid or the signature fails is the "normal" behaviour as things stand. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto
More specifically what you are seeing is that it will let you zoom in beyond zoom 8 but you are seeing data that was simplified on the basis that it would be shown at zoom 8 where those artefacts would not be visible. Tom On 26/05/2020 09:59, Simon Poole wrote: I think you are missing "Only zoom 0 to 8 has been implemented so far. I started at zoom 0 and am working my way down." Simon Am 26.05.2020 um 10:42 schrieb Maarten Deen: On 2020-05-26 10:15, Paul Norman via dev wrote: On 2020-05-25 1:15 a.m., Maarten Deen wrote: Still, it looks to be a very simplified subset of the complete data. So I'd be interested to see how this works on a full dataset. No, it has the full data except for admin boundaries and bay/straight names on zoom 7 and 8. When you compare it to OpenStreetMap Carto they're pretty similar. There are some labeling differences with sizes of labels and when labels come in, but those don't have anything to do with performance or size. No, that's not what I'm seeing. I am seeing very basic and rectangular landuses, obviously simplified, along with waterways, railways, motorways, trunk, primary secondary roads and they too have been simplified, to the extent that parallel ways on motorways are now crossing eachother. This is in my area: https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html#12.14/51.36196/6.08322 https://imgur.com/a/WcYlVUc Regards, Maarten ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] planet.osm.org is verry slow
On 25/01/2020 15:45, Grant Slater wrote: The minutely, hourly and daily diff files will only take a second or 2 extra to download with the current late limits. The minutely files won't normally be affected at all as the limit only kicks in for files over 512Kb. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Database schema
Not quite - the history tables have all versions including the current version. So when a change is made to a node the current_nodes table is changed to reflect the new details and a new record is added to nodes with a new version number and the same details. Yes, that is denormalised, but all real world databases are to some extent ;-) Tom On 09/01/2020 11:54, Lorenzo Stucchi wrote: So the meaning is that the last version of a node is saved in a table called node_current, instead, all the old version are saved into a node table that has the number of the version? So the node is created in the current_node table, when it is modified the raw is moved into the nodes table and the current_nodes is updated with the new change. It is correct? Thanks for pointing out this, Lorenzo Il giorno 9 gen 2020, alle ore 12:45, Tom Hughes ha scritto: Because 99% of the time all that is needed is the current version of the object. Now you could probably do something clever with a flag to mark the current version which was included in the index, or as a condition on a partial index, so that you could efficiently find the current versions but bear in mind this schema originated many years ago on a different database engine with less capabilities. Basically a lot of what you see is history rather than design. Tom On 09/01/2020 11:39, Lorenzo Stucchi wrote: Thanks to both, for the redaction I forgot to add them, I initially skipped and after I forgot to put them. Thanks also Maarteen for the quick explanation of the parameters. Can you quickly explain the reason for having double tables for the element, like nodes and current_nodes? It is also related to the change in the license? Thanks, Lorenzo Il giorno 9 gen 2020, alle ore 12:27, Tom Hughes ha scritto: There are redactions as well, when data has had to be removed and hidden from the history for copyright reasons or whatever. There is a list: https://www.openstreetmap.org/redactions Tom On 09/01/2020 11:17, Maarten Deen wrote: Redaction_id will have bearing on the redaction bot https://wiki.openstreetmap.org/wiki/OSMF_Redaction_Bot Background: when OSM changed to ODbl, all changes made by people who did not agree had to be redacted. visible in the changeset will be the same as for node/way/relation: you can delete an item, and when it is deleted, visible=0. Maarten On 2020-01-09 11:29, Lorenzo Stucchi wrote: Dear all, After the discussion that I started about the database schema I tried to create a wiki page that explains it, I started the page on my user wiki-page [1]. I started with few tables, but some elements present in the tables are not so clear to me. So If you wanna try to contribute to that page, since a description of the database can be provided to everyone. I will continue to modify it ,trying to understand all the tables. Thanks to everyone that will help, or just make a suggestion about it. Best, Lorenzo [1] https://wiki.openstreetmap.org/wiki/User:LorenzoStucchi/Description_DatabaseSchema Il giorno 4 gen 2020, alle ore 23:01, Martin Koppenhoefer ha scritto: sent from a phone On 4. Jan 2020, at 17:28, Jean Marie Falisse wrote: Is it still true that in the OSM database, areas are not represented as such? areas can be represented as areas through multipolygon relations which are always areas or by help of an additional tag (area=yes/no), or through plausibility (tags and their combinations may imply an area or not). There isn’t a dedicated area object, maybe this is what you meant. Areas are represented with ways, and tags or relations are required to define the ways as areas. That would mean, for instance, that a pedestrian zone, let’s say a big square in a city, cannot be made to be crossed diagonally when used in a route planner. Am I right? typically routing engines operate on graphs, i.e. they do not route diagonally across areas, but this isn’t related to the question whether there is a dedicated datatype for areas or not. Cheers Martin ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Database schema
Because 99% of the time all that is needed is the current version of the object. Now you could probably do something clever with a flag to mark the current version which was included in the index, or as a condition on a partial index, so that you could efficiently find the current versions but bear in mind this schema originated many years ago on a different database engine with less capabilities. Basically a lot of what you see is history rather than design. Tom On 09/01/2020 11:39, Lorenzo Stucchi wrote: Thanks to both, for the redaction I forgot to add them, I initially skipped and after I forgot to put them. Thanks also Maarteen for the quick explanation of the parameters. Can you quickly explain the reason for having double tables for the element, like nodes and current_nodes? It is also related to the change in the license? Thanks, Lorenzo Il giorno 9 gen 2020, alle ore 12:27, Tom Hughes ha scritto: There are redactions as well, when data has had to be removed and hidden from the history for copyright reasons or whatever. There is a list: https://www.openstreetmap.org/redactions Tom On 09/01/2020 11:17, Maarten Deen wrote: Redaction_id will have bearing on the redaction bot https://wiki.openstreetmap.org/wiki/OSMF_Redaction_Bot Background: when OSM changed to ODbl, all changes made by people who did not agree had to be redacted. visible in the changeset will be the same as for node/way/relation: you can delete an item, and when it is deleted, visible=0. Maarten On 2020-01-09 11:29, Lorenzo Stucchi wrote: Dear all, After the discussion that I started about the database schema I tried to create a wiki page that explains it, I started the page on my user wiki-page [1]. I started with few tables, but some elements present in the tables are not so clear to me. So If you wanna try to contribute to that page, since a description of the database can be provided to everyone. I will continue to modify it ,trying to understand all the tables. Thanks to everyone that will help, or just make a suggestion about it. Best, Lorenzo [1] https://wiki.openstreetmap.org/wiki/User:LorenzoStucchi/Description_DatabaseSchema Il giorno 4 gen 2020, alle ore 23:01, Martin Koppenhoefer ha scritto: sent from a phone On 4. Jan 2020, at 17:28, Jean Marie Falisse wrote: Is it still true that in the OSM database, areas are not represented as such? areas can be represented as areas through multipolygon relations which are always areas or by help of an additional tag (area=yes/no), or through plausibility (tags and their combinations may imply an area or not). There isn’t a dedicated area object, maybe this is what you meant. Areas are represented with ways, and tags or relations are required to define the ways as areas. That would mean, for instance, that a pedestrian zone, let’s say a big square in a city, cannot be made to be crossed diagonally when used in a route planner. Am I right? typically routing engines operate on graphs, i.e. they do not route diagonally across areas, but this isn’t related to the question whether there is a dedicated datatype for areas or not. Cheers Martin ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Database schema
There are redactions as well, when data has had to be removed and hidden from the history for copyright reasons or whatever. There is a list: https://www.openstreetmap.org/redactions Tom On 09/01/2020 11:17, Maarten Deen wrote: Redaction_id will have bearing on the redaction bot https://wiki.openstreetmap.org/wiki/OSMF_Redaction_Bot Background: when OSM changed to ODbl, all changes made by people who did not agree had to be redacted. visible in the changeset will be the same as for node/way/relation: you can delete an item, and when it is deleted, visible=0. Maarten On 2020-01-09 11:29, Lorenzo Stucchi wrote: Dear all, After the discussion that I started about the database schema I tried to create a wiki page that explains it, I started the page on my user wiki-page [1]. I started with few tables, but some elements present in the tables are not so clear to me. So If you wanna try to contribute to that page, since a description of the database can be provided to everyone. I will continue to modify it ,trying to understand all the tables. Thanks to everyone that will help, or just make a suggestion about it. Best, Lorenzo [1] https://wiki.openstreetmap.org/wiki/User:LorenzoStucchi/Description_DatabaseSchema Il giorno 4 gen 2020, alle ore 23:01, Martin Koppenhoefer ha scritto: sent from a phone On 4. Jan 2020, at 17:28, Jean Marie Falisse wrote: Is it still true that in the OSM database, areas are not represented as such? areas can be represented as areas through multipolygon relations which are always areas or by help of an additional tag (area=yes/no), or through plausibility (tags and their combinations may imply an area or not). There isn’t a dedicated area object, maybe this is what you meant. Areas are represented with ways, and tags or relations are required to define the ways as areas. That would mean, for instance, that a pedestrian zone, let’s say a big square in a city, cannot be made to be crossed diagonally when used in a route planner. Am I right? typically routing engines operate on graphs, i.e. they do not route diagonally across areas, but this isn’t related to the question whether there is a dedicated datatype for areas or not. Cheers Martin ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export: (limit is 50000).
On 06/08/2019 14:45, Dave F via dev wrote: Why are you mentioning 'rendering'? Because I thought we were talking about map exports? I assume you meant the raw data export? That is the standard API limit - all that export does is redirect to the same API that JOSM etc use. That really isn't something that I would expect anybody much to use - if you want bulk data then sue the planet. The API is for editors. Again we should really never have added that to the share tab as it just encourages people to think that is the correct way to reuse OSM data. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export: (limit is 50000).
On 06/08/2019 14:24, Dave F via dev wrote: Is this based on server & connection speeds etc? If so has it been reviewed recently? With the increase in general computing power is there a reason this limit could not be increased? Rendering custom maps is very expensive and is not really a core part of our mission - we should probably never have added that feature really. Every time that call is used you are going direct to one of the render servers whose main job is to render tiles for the map and you're making it do a custom select from the database just for and then render that data. The node limit is basically about limiting the amount of data that has to be sucked out the database and manipulated to produce the result. While compute power may have increased somewhat so have the number of users hitting that endpoint... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Auto adding attribution to image creation.
On 06/08/2019 13:29, Dave F via dev wrote: On 06/08/2019 12:26, Tom Hughes wrote: On 06/08/2019 12:04, Dave F via dev wrote: A user has asked why the image creation tool under 'Share' couldn't automatically add an attribution. It would certainly save me a lot of email sending asking users to add it. If you mean the option I'm surprised your confused. I thought I was perfectly clear. The "share" tool offers a number of options and I just wanted to be clear which one we were talking about. that gives you an image based on the default rendering then the answer is that all that option does is to to a custom render using mapnik, and that render has no way to add an attribution. Would it be much coding effort? Yes. I mean you can certainly do it, but it means writing a whole bunch of code to work out what font size to use then render some text and overlay it on the mapnik generated image. There must be calculations performed to create the clipped image especially considering the Scale: option provided. Inserting an image of the attribution into the corner of the map image at a defined percentage of its size can't add that much additional overheads, There are plenty of 'image stamper' programs on the market which do similar. The script is here: https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/templates/default/export.erb Patches are welcome. Make sure they work for all the output formats ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Auto adding attribution to image creation.
On 06/08/2019 12:04, Dave F via dev wrote: A user has asked why the image creation tool under 'Share' couldn't automatically add an attribution. It would certainly save me a lot of email sending asking users to add it. If you mean the option that gives you an image based on the default rendering then the answer is that all that option does is to to a custom render using mapnik, and that render has no way to add an attribution. Would it be much coding effort? Yes. I mean you can certainly do it, but it means writing a whole bunch of code to work out what font size to use then render some text and overlay it on the mapnik generated image. Then you need somebody to answer all the complaints when that text gets dropped over the top of something important. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 403 forbidden
We don't offer any sort of authenticated tile service. Tom On 31/05/2019 05:47, Vijaya Nand wrote: Please suggest me how I can get OSM API user id and password so that I can pass that to authenticate. Please suggest me how I can check what's wrong with gmap.net <http://gmap.net>. On Wed, 29 May 2019, 17:09 Mateusz Konieczny, <mailto:matkoni...@tutanota.com>> wrote: Technical requirements are at https://operations.osmfoundation.org/policies/tiles/ To check what gmap.net <http://gmap.net> is doing you need to either check its source code, capture your network traffic and review it (with for example Wireshark) or use program that is not maliciously violating OSM policies. 29 May 2019, 13:18 by vijaya21tiw...@gmail.com <mailto:vijaya21tiw...@gmail.com>: I would appreciate if you can let me know the exact request header. ___ dev mailing list dev@openstreetmap.org <mailto:dev@openstreetmap.org> https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API Basic Authentication
I only reverted upload, not the method he is using. Tom On 30/05/2019 20:43, Simon Poole wrote: See https://github.com/zerebubuth/openstreetmap-cgimap/issues/189 Your app should be working again right now as Tom has reverted back to the Rails implemetation, still you should likely be using OAuth to start with. Simon Am 30.05.2019 um 21:33 schrieb Colin Smale: A (private) program I use which accesses the OSM API has stopped working since the last time I used it, a couple of weeks ago. Read-only calls to the API, including a (proven correct) Authentication header are now failing with 401 Unauthorized, with the returned body indicating a problem with the username/password. The same call without the Authorization header succeeds. I swear nothing has changed on my side; double-checking the auth header with Fiddler shows the username/password I expect, and I can still logout/login using these values (which I haven't changed). Is there anything going on, or has anything changed on the API, that may be causing this? Sample URL: GET on https://api.openstreetmap.org/api/0.6/relation/8465619 I know I can just remove the authentication - it was added for "future use" anyway - but why has it suddenly broken? Thanks, Colin ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API Basic Authentication
On 30/05/2019 20:33, Colin Smale wrote: A (private) program I use which accesses the OSM API has stopped working since the last time I used it, a couple of weeks ago. Read-only calls to the API, including a (proven correct) Authentication header are now failing with 401 Unauthorized, with the returned body indicating a problem with the username/password. The same call without the Authorization header succeeds. I swear nothing has changed on my side; double-checking the auth header with Fiddler shows the username/password I expect, and I can still logout/login using these values (which I haven't changed). Is there anything going on, or has anything changed on the API, that may be causing this? Sample URL: GET on https://api.openstreetmap.org/api/0.6/relation/8465619 I know I can just remove the authentication - it was added for "future use" anyway - but why has it suddenly broken? It's a cgimap bug - previously it just ignored basic authentication which was fine because it only handled calls where it was optional. The version does do it but has a bug - we have a fix in hand which should be rolled out shortly. In the meantime try using your username instead of email address and make sure you get he case right and it will hopefully work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM tile server issue
On 30/05/2019 19:43, Mateusz Konieczny wrote: 30 May 2019, 20:21 by rodo...@justmapzz.com <mailto:rodo...@justmapzz.com>: I am the main developer of Justmapzz, which uses GMAP.NET for map viewing (...) In the mean time, what must we do to comply with your usage policy, other than changing the user-agent, which appeared to be insufficient? See https://operations.osmfoundation.org/policies/tiles/ for tile usage policy > Heavy use (e.g. distributing an app that uses tiles from openstreetmap.org) is > forbidden without prior permission from the System Administrators. Do you have such permission? Argh. That line needs to be deleted... We are not in the business of granting special permissions and any such queries will just get pointed at the usage policy. His real problem (aside from his attitude) is that gmap.net is also sending a fake referer of http://www.openstreetmap.org/ which is causing it to be blocked. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] oauth token lifetime
On 27/04/2019 14:37, Jiri Vlasak wrote: On Fri, Apr 26, 2019 at 07:28:39PM +0100, Tom Hughes wrote: On 26/04/2019 19:06, Jiri Vlasak wrote: This approach is similar to one used by HOT Tasking Manager [1]. In my "oauth settings" section I have many many "Tasking Manager 3 - Prod" tokens. And I feel this approach is not right. That's usually because the client is broken and is not storing the token but is instead requesting a new one every time you use it. That's my guess too. So, I would like to write it better. My problem is that I am quite confused by OAuth. If I understand it correctly, OAuth is here for authorization. But, in my case (and in the case of HOT Tasking Manager), the use case is authentication. Yes it is really abuse of OAuth in general but is common. Note that OAuth 2 (in the form of OpenID Connect) has basically merged the two use cases anyway. So maybe I should ask - is it possible to authenticate to osm.org? Well yes, that is what OAuth does. What is happening here is using your osm.org account to authenticate to a third party site. That works if the third party is prepared to accept you allowing it to access osm.org as valid authentication. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] oauth token lifetime
On 26/04/2019 19:06, Jiri Vlasak wrote: I would like to ask about the lifetime of OAuth token. I use OSM OAuth to log into my web application. However, there is new token each time I log into the web page. I don't believe there is any expiry - once you have an access token you can use it for as long as you want. This approach is similar to one used by HOT Tasking Manager [1]. In my "oauth settings" section I have many many "Tasking Manager 3 - Prod" tokens. And I feel this approach is not right. That's usually because the client is broken and is not storing the token but is instead requesting a new one every time you use it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Just Joined List
I think that is underplaying things... I don't speak for the overpass maintainers but I can't imagine that hitting it every three seconds for every vehicle that you are tracking is going to go down well - at least if you are tracking any even vaguely significant number of vehicles. If you are building a business on this and selling this to people as a service then you really should be looking to run your own overpass instance or something. Tom On 18/04/2019 12:41, Rory McCann wrote: This can be done with the Overpass API, not the OSM editing API way(around:25,LAT,LON)["maxspeed"];out; This should give you all ways within 25 m of a point with the maxpseed tag. Be warned though: Most of the main overpass servers do have access limits, and building a business relying on things that can be shut off without warning might not be a good idea. On 16/04/2019 09:09, TrackingCentral wrote: Hi I am wanting to be able to return the current road my passing a http request to the api endpoint passing the co ordinates of the users location with each request. Just wondering if this function already exist and it is a matter of sending the http request to the api each time ??? Basically I have gps tracking devices that send location data to my server every 3 second and want the road speed of their location determined by the api and returned each time I send the http request to the api endpoint. Can you also advise the variable name that is returned that will hold the road speed. Claude Raiola TrackingCentral Pty Ltd 61-414 228 948 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] slow osm.org tile server
On 09/04/2019 19:39, Wolfram Schneider wrote: On Mon, 25 Mar 2019 at 18:16, Wolfram Schneider wrote: Hi, I noticed that the standard OSM tile servers (N.tile.openstreetmap.org) are currently slow. On the site https://mc.bbbike.org/mc/ you will see that OSM is the slowest, and takes at least 5 seconds to get all tiles. The other servers responses in less than a second. Downloading a single tile is also always slow: curl https://b.tile.openstreetmap.org/11/1100/671.png >/dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 41017 100 410170 0 7658 0 0:00:05 0:00:05 --:--:-- 7146 it seems that there is a delay of 5 seconds until the tile is fully delivered, and the download rate is at 7Kbyte/s. I tried this from different locations (Bay Area, NYC, Germany) - the result is always the same. it was better in the last week, down to 2-3 seconds. But not it is slow as hell again and takes more than 6.5 seconds to fetch a single tile: time curl -sSf https://c.tile.openstreetmap.org/11/1100/671.png >/dev/null real 0m6.587s user 0m0.017s sys 0m0.009s you can repeat the request and it is still slow (5+ seconds). who is in charge of the HTTPS setup for OSM? Using curl like that will be slow beause you are being put in a deliberate slow lane when not coming via the web site. Tom -Wolfram PS: if I do not use HTTPS and instead plain old HTTP, it will take only 0.3 - 0.6 seconds. Any idea whats wrong with the HTTPS setup for the tile servers? -Wolfram -- Wolfram Schneider https://wolfram.schneider.org Planet.osm extracts: https://extract.bbbike.org BBBike Map Compare: https://mc.bbbike.org/mc -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Synchronizing Charge Station Data
On 14/02/2019 14:42, Wolfgang Fahl wrote: Indeed I intend to create my own website with a database that "synchronizes" with other sites. So the bulk operations will be limited to initially filling the database and synchronize changes that might arise e.g. from checking records against user databases. For the edit operations i intend to link directly to the source of the data so if someone needs to modify info on a charging station he can do so directly e.g. in openchargemap or openstreetmap. Right, but you shouldn't do the initial population using the API but rather you should start from a planet dump and then use the replication feed for changes. When it comes to feeding back a change the API is of course the right thing to use - note that we prefer edits to be made under the account of the person making the change rather then batching them altogether under one account. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Synchronizing Charge Station Data
On 14/02/2019 11:41, Wolfgang Fahl wrote: For the "where" part I need access to a list of vehicle charging stations. I tried the following options: ... For integration openstreetmap I'd need some input and advice. Currently I am looking for a java library to be useable and I found: https://github.com/westnordost/osmapi as well as https://github.com/osmapi/osmapi-java The second library seems to be much simpler but not as well maintained. I have already forked it and would like to know whether it makes sense to base my efforts on that library. I'm not sure what you mean by "integration" exactly but please don't try and use the openstreetmap.org API to fetch lists of charging points in real time - that is most definitely not an appropriate use. The API is for editing and consumers of the data should either maintain their own database updated using the replication feeds or use a query orientated service like overpass. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Services on dev server down
This is not actually related, as the dev server wasn't being moved. The master API should be working again now. Tom On 26/07/18 17:25, Xavier Barnada wrote: Hi Nick, The operations team is moving the servers Check this https://blog.openstreetmap.org/2018/07/25/server-moves-imperial-equinix/ Best reggards Xavier Barnada El jue., 26 jul. 2018 a las 18:11, Nick Whitelegg (mailto:nick.whitel...@solent.ac.uk>>) escribió: Hi, Looks like some features on the dev server are down, presumably down to the move... just checking, are the admins aware of this? It's not mentioned on the wiki page on service availability. The dev server version of the API is working, however the website itself is down (which in turn affects OAuth authentication): https://master.apis.dev.openstreetmap.org/ Apologies if you know this already! Thanks, Nick ___ dev mailing list dev@openstreetmap.org <mailto:dev@openstreetmap.org> https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Synchronous mode
On 20/02/18 21:16, Paul Norman wrote: The data loss potential is very minimal, particularly since anything that brings down the DB server is likely to cause much larger interruptions to mapping than the loss of 5 seconds of PostgreSQL replication. I'd also point out that the data loss risk that page talks about is only if the primary is a total loss and you decide to flip to the secondary. If the primary crashes and restarts then the secondary will replay the logs in the same way the primary does and both will have the same view of the data. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSOC project
On 18/02/18 21:10, Jason Remillard wrote: I have added a GSOC project idea to add a developer key system to our tile services and Nominatim. The key system will eventually provide a founding source for the OSMF, to allow the OSMF to support heavy commercial users via full time system administrators and developers. I am able and willing to mentor the project. With respect that's ridiculous. Adding a key system is fairly trivial and certainly not worthy of a GSOC project. The work is in providing the technical infrastructure to run a service that can cope with the load, and staffing a billing and support department to respond to the customers. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] smoothness data in gpx files for GPS tracks on osm.org?
On 28/01/18 07:59, Johannes wrote: Therefore a central data repository is needed. Do you think it's a good idea to store such enriched GPX data in the public GPS tracks repository on openstreetmap.org and make appropriate changes to the database schema and API so that these additional metadata are preserved when exporting GPX, so that on the one hand the GPS tracks can be made available to the public and on the other hand special client software can visualize the vibration metadata. Not really. There are plenty of general purpose GPX repositories - the purpose of the GPX tracks stored on osm.org is to support mapping and this doesn't really seem to be useful for that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Scale of downloaded images seems to vary.
On 11/01/18 10:47, Tom Hughes wrote: On 11/01/18 10:38, Bjoern Hassler wrote: (1) DPI on exported images Actually isn't the real problem here just needing to know what DPI is being being assumed by mapnik when rendering? IIRC it's 96dpi? As you say (and also in the link Yves posted) it's about 90.7dpi, standard pixel size of 0.28 millimeters as defined by the OGC (Open Geospatial Consortium) SLD (Styled Layer Descriptor). However, the images downloaded are claiming 72dpi. I need to check whether they don't have dpi metadata (and therefore my OS assumes 72) or whether they are tagged incorrectly. Either way, that sounds like a discrepancy though, right? If you're fetching PNG then does PNG even have a way of specifying the DPI in the format? Per https://en.wikipedia.org/wiki/Portable_Network_Graphics#Ancillary_chunks I think that a pHYs chunk could store it but our images don't appear to have that: % ./pngcheck -v map.png File: map.png (205670 bytes) chunk IHDR at offset 0xc, length 13 1192 x 1018 image, 32-bit RGB+alpha, non-interlaced chunk IDAT at offset 0x00025, length 32768 zlib: deflated, 32K window, default compression chunk IDAT at offset 0x08031, length 32768 chunk IDAT at offset 0x1003d, length 32768 chunk IDAT at offset 0x18049, length 32768 chunk IDAT at offset 0x20055, length 32768 chunk IDAT at offset 0x28061, length 32768 chunk IDAT at offset 0x3006d, length 8933 chunk IEND at offset 0x3235e, length 0 No errors detected in map.png (9 chunks, 95.8% compression). I suspect 72 is just an OS default. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Scale of downloaded images seems to vary.
On 11/01/18 10:38, Bjoern Hassler wrote:
(1) DPI on exported images
Actually isn't the real problem here just needing to know what DPI
is being being assumed by mapnik when rendering?
IIRC it's 96dpi?
As you say (and also in the link Yves posted) it's about 90.7dpi,
standard pixel size of 0.28 millimeters as defined by the OGC (Open
Geospatial Consortium) SLD (Styled Layer Descriptor). However, the
images downloaded are claiming 72dpi. I need to check whether they don't
have dpi metadata (and therefore my OS assumes 72) or whether they are
tagged incorrectly.
Either way, that sounds like a discrepancy though, right?
If you're fetching PNG then does PNG even have a way of specifying the
DPI in the format?
Frankly it's not something I'm going to lose much sleep over and may
well not be anything we have any control over.
(2) "project the bounding box from EPSG:4326 lat/lon to spherical
mercator which gives us coordinates on a projected sheet measuring
roughly 40075016m on each edge (2 x PI x assumed earth radius)."
That's very helpful. What is the function (of latitude) that maps the
sheet to the smaller scale map? I'd assumed cos(lat), but it seems to be
more complicated. I can dig around, but if you happen to know it, thenÂ
don't need to dig around. The code has this:
  scale = float(form.getvalue("scale"))
  width = int(bbox.width() / scale / 0.00028)
  height = int(bbox.height() / scale / 0.00028)
where I assume form.getvalue fetches the "mapnik_" form. So,
equivalently, it would be about the variation of the bbox.width() with
lat, in the  spherical mercator projection. Any thoughts on this?
I don't think there is one simple function. We (or rather mapnik) just
uses the proj4 library like everybody else that does this stuff. You can
see the precise configuration we feed it a few lines above that in the
source.
It then does a load of funky maths that I'm not even going to try to
understand.
(3) Filing a bug: Clearly there's nothing wrong with the rendering (bar
issue 1 above?). However, one might say that the 'scale' label on the
box is misleading to a casual user, as users would assume geographical
scale, rather than mapnik_scale. Would it be helpful to users to have a
few words underneath to the scale box, saying "Note that this is not
geographical scale." and link to page that explained how to convert?
I'm not really sure what you mean by geographical scale?
Like any other projected map the value we show is the amount by which
the projected sheet is scaled. Basically you unwrap the globe (or part
of the globe that you are dealing with) and do the necessary funky
stretching to make it a flat sheet than you scale that sheet by the
specified amount. That is how every printed map you see works.
Because this is a digital version there is then a second step of how
many pixels you use for each physical unit.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Scale of downloaded images seems to vary.
Looks like we are using 90dpi actually. The key code is here:
https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/templates/default/export.erb#L121
We project the bounding box from EPSG:4326 lat/lon to spherical mercator
which gives us coordinates on a projected sheet measuring roughly
40075016m on each edge (2 x PI x assumed earth radius).
We then divide by the scale factor and then convert metres to pixels by
dividing by 0.00028 which comes from:
1 / 39.701 / 90
Where we divide by 39.701 to convert from metres to inches and then by a
further 90 to convert to pixels at 90 dpi.
Tom
On 11/01/18 08:52, Tom Hughes wrote:
Actually isn't the real problem here just needing to know what DPI is
being being assumed by mapnik when rendering?
IIRC it's 96dpi?
Tom
On 11/01/18 08:50, Tom Hughes wrote:
Please don't - it has nothing to do with the web site code.
Please go and read about projections instead.
Tom
On 11/01/18 08:21, Darafei "Komяpa" Praliaskouski wrote:
Hi,
As long as there is nobody on the list can make sense of the values
for almost two weeks, I'd say it should be considered a bug and filed
towards https://github.com/openstreetmap/openstreetmap-website/issues
чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler <bjohas...@gmail.com
<mailto:bjohas%2...@gmail.com>>:
Dear friends,
I was just wondering whether anybody else had any thoughts on this?
Any tips on making sense of the mapnik_scale would be greatly
appreciated!
Bjoern
On 3 January 2018 at 17:21, Bjoern Hassler <bjohas...@gmail.com
<mailto:bjohas...@gmail.com>> wrote:
Hi Bryan, hi Darafei,
That's helpful, thanks. So we know that the calculation from the
bbox is correct.
However, I guess we don't know about how pixels translate to
real-word dims? (Or, equicvalenly, how pixels relate to the
lat-lon extent.)
Thanks!
Bjoern
On 2 January 2018 at 14:46, Bryan Housel <br...@7thposition.com
<mailto:br...@7thposition.com>> wrote:
Bjoern, maybe the geo functions used in iD might be a
helpful reference:
https://github.com/openstreetmap/iD/blob/master/modules/geo/geo.js
The numbers I got from comparing the bbox sizes are pretty
close to your numbers.
bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
dLat1 = bbox1[1][0] - bbox1[0][0]
> 0.111031055
iD.geoLatToMeters(dLat1)
> 12359.91438226802
dLon1 = bbox1[1][1] - bbox1[0][1]
> 0.117417321
iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2)
> 11884.145336433623
(image1 is 11.884 km x 12.359 km)
bbox2 = [[48.632228,-101.369133], [48.691074,-101.251717]]
dLat2 = bbox2[1][0] - bbox2[0][0]
> 0.058846262
iD.geoLatToMeters(dLat2)
> 6550.706755221268
dLon2 = bbox2[1][1] - bbox2[0][1]
> 0.117416574
iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2)
> 8604.30156213755
(image2 is 8.604 km x 6.550 km)
Bryan
On Jan 1, 2018, at 6:56 AM, Bjoern Hassler
<bjohas...@gmail.com <mailto:bjohas...@gmail.com>> wrote:
Hi Darafei, dear all,
Thanks, but I still cannot get this to work.
I've now calculated real_scale = mapnik_scale / cos(lat),
and used the real_scale, to calculate:
pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
However, there's still a latitude-dependent discrepancy
(see below). I could try to fit that to latitude, to see
what the formula is, but I'm hoping somebody has the
answer (or can let me know what I got wrong!)
Happy new year!
Bjoern
*Example 1:*
http://www.openstreetmap.org/#map=13/24.1788/49.3092
bbox = [24.123255,49.250507; 24.234286,49.367924]
bbox size in degrees (lon, lat) = 0.117416, 0.111031
*Pixels ('Image ... at'):* 1945 x 2016;
*mapnik_scale* 1 : 24000; *real scale *1 : 26308
Image dim (1 : 26308, 72dpi): 686 mm x 711 mm
Real world dim (1:1, from pixels): *18.051 km x 18.71 km*
Real world dim (1:1, latlon): *11.911 km x 12.346 km*
Ratio (dim pixels/ dim latlon): 1.516 ; 1.515
*Example 2:*
http://www.openstreetmap.org/#map=13/48.6617/-101.3104
bbox = [48.632228,-101.369133; 48.691074,-101.251717]
bbox size in degrees (lon, lat) = 0.117416, 0.058846
*Pixels ('Image ... at'):* 1945 x 1476;
*mapnik_scale* 1 : 24000; *real scale *1 : 36336
Re: [OSM-dev] Scale of downloaded images seems to vary.
Actually isn't the real problem here just needing to know what DPI is
being being assumed by mapnik when rendering?
IIRC it's 96dpi?
Tom
On 11/01/18 08:50, Tom Hughes wrote:
Please don't - it has nothing to do with the web site code.
Please go and read about projections instead.
Tom
On 11/01/18 08:21, Darafei "Komяpa" Praliaskouski wrote:
Hi,
As long as there is nobody on the list can make sense of the values
for almost two weeks, I'd say it should be considered a bug and filed
towards https://github.com/openstreetmap/openstreetmap-website/issues
чт, 11 янв. 2018 г. в 2:05, Bjoern Hassler <bjohas...@gmail.com
<mailto:bjohas%2...@gmail.com>>:
Dear friends,
I was just wondering whether anybody else had any thoughts on this?
Any tips on making sense of the mapnik_scale would be greatly
appreciated!
Bjoern
On 3 January 2018 at 17:21, Bjoern Hassler <bjohas...@gmail.com
<mailto:bjohas...@gmail.com>> wrote:
Hi Bryan, hi Darafei,
That's helpful, thanks. So we know that the calculation from the
bbox is correct.
However, I guess we don't know about how pixels translate to
real-word dims? (Or, equicvalenly, how pixels relate to the
lat-lon extent.)
Thanks!
Bjoern
On 2 January 2018 at 14:46, Bryan Housel <br...@7thposition.com
<mailto:br...@7thposition.com>> wrote:
Bjoern, maybe the geo functions used in iD might be a
helpful reference:
https://github.com/openstreetmap/iD/blob/master/modules/geo/geo.js
The numbers I got from comparing the bbox sizes are pretty
close to your numbers.
bbox1 = [[24.123255,49.250507], [24.234286,49.367924]]
dLat1 = bbox1[1][0] - bbox1[0][0]
> 0.111031055
iD.geoLatToMeters(dLat1)
> 12359.91438226802
dLon1 = bbox1[1][1] - bbox1[0][1]
> 0.117417321
iD.geoLonToMeters(dLon1, (bbox1[1][0] + bbox1[0][0])/2)
> 11884.145336433623
(image1 is 11.884 km x 12.359 km)
bbox2 = [[48.632228,-101.369133], [48.691074,-101.251717]]
dLat2 = bbox2[1][0] - bbox2[0][0]
> 0.058846262
iD.geoLatToMeters(dLat2)
> 6550.706755221268
dLon2 = bbox2[1][1] - bbox2[0][1]
> 0.117416574
iD.geoLonToMeters(dLon2, (bbox2[1][0] + bbox2[0][0])/2)
> 8604.30156213755
(image2 is 8.604 km x 6.550 km)
Bryan
On Jan 1, 2018, at 6:56 AM, Bjoern Hassler
<bjohas...@gmail.com <mailto:bjohas...@gmail.com>> wrote:
Hi Darafei, dear all,
Thanks, but I still cannot get this to work.
I've now calculated real_scale = mapnik_scale / cos(lat),
and used the real_scale, to calculate:
pixels * (72/2.54 pixels/cm) * real_scale = real_world_dim
However, there's still a latitude-dependent discrepancy
(see below). I could try to fit that to latitude, to see
what the formula is, but I'm hoping somebody has the
answer (or can let me know what I got wrong!)
Happy new year!
Bjoern
*Example 1:*
http://www.openstreetmap.org/#map=13/24.1788/49.3092
bbox = [24.123255,49.250507; 24.234286,49.367924]
bbox size in degrees (lon, lat) = 0.117416, 0.111031
*Pixels ('Image ... at'):* 1945 x 2016;
*mapnik_scale* 1 : 24000; *real scale *1 : 26308
Image dim (1 : 26308, 72dpi): 686 mm x 711 mm
Real world dim (1:1, from pixels): *18.051 km x 18.71 km*
Real world dim (1:1, latlon): *11.911 km x 12.346 km*
Ratio (dim pixels/ dim latlon): 1.516 ; 1.515
*Example 2:*
http://www.openstreetmap.org/#map=13/48.6617/-101.3104
bbox = [48.632228,-101.369133; 48.691074,-101.251717]
bbox size in degrees (lon, lat) = 0.117416, 0.058846
*Pixels ('Image ... at'):* 1945 x 1476;
*mapnik_scale* 1 : 24000; *real scale *1 : 36336
Image dim (1 : 36336, 72dpi): 686 mm x 521 mm
Real world dim (1:1, from pixels): *24.932 km x 18.92 km*
Real world dim (1:1, latlon):*8.624 km x 6.543 km*
Ratio (dim pixels/ dim latlon): 2.891 ; 2.891
On 31 December 2017 at 18:59, Darafei "Komяpa"
Praliaskouski <m...@komzpa.net <mailto:m...@komzpa.net>> wrote:
Images are in Spherical Mercator EPSG:3857 projection,
so linear scale is off by cos(lat).
On Sun, Dec 31, 2017, 20:07 Bjoern Hassler
<bjohas...@gmail.com <mailto:bjo
Re: [OSM-dev] Scale of downloaded images seems to vary.
___ dev mailing list dev@openstreetmap.org <mailto:dev@openstreetmap.org> https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tile Rendering Queue
On 18/11/17 16:55, Daniel Koć wrote: W dniu 15.11.2017 o 16:20, Darafei "Komяpa" Praliaskouski pisze: Tile CDN is highly loaded during daytime and not loaded on night. There is a peak after each stylesheet update. Monitoring: https://munin.openstreetmap.org/openstreetmap/render.openstreetmap/index.html#renderd Is there something wrong with Munin lately? Thanks for the the report - this should be fixed now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] History feed stopped working
On 27/10/17 15:20, Tomas Straupis wrote: For two days history feed is throwing 500 error: http://www.openstreetmap.org/history/feed/?bbox=20.9,53.95,26.83,56.45 Is this intended? Maybe url has changed? Thanks for the report - a fix for this is rolling out now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet PBF too small
On 03/10/17 22:06, Peter wrote: it looks like the current planet PBF is with 21GB a bit too small: https://planet.openstreetmap.org/ It is usually around 37GB https://planet.openstreetmap.org/pbf/ http://ftp.heanet.ie/mirrors/openstreetmap.org/pbf/ Is there a problem or was there a cleanup? Is that this weeks? or last weeks? There shouldn't be one for this week because the backup (on which it is based) failed so if one has somehow appeared then it will be incomplete. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSRM on osm.org not working
On 01/10/17 14:28, joost schouppe wrote: Apparently, OSRM routing on osm.org <http://osm.org> has been down for a few days. I have no idea how the implementation really works, or where the correct tracker would be. But I'm sure someone here knows. See https://github.com/openstreetmap/openstreetmap-website/pull/1637. Unfortunately the OSRM demo server that we were using was taken offline without any warning I think on the assumption that we would be happy to simply switch to using a free account on the commercial Mapbox routing platform in it's place but I'm reluctant to do that. The problem is that as far as I know there aren't really any practical non-commercial routing solutions using OSM data that we could switch to without having to run our own, and that will obviously take time to arrange. In the short term we likely need to merge that PR with a few tweaks but there remains a question about how we avoid giving undue promotion to one particular commercial solution. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Andy Allan joining web site maintainers
On 10/07/17 13:25, Matthijs Melissen wrote: On 10 July 2017 at 11:14, Andy Allan <gravityst...@gmail.com> wrote: Thanks Tom. My intentions for the next few months are to continue to do whatever I can to encourage new contributors. I've done a lot of refactoring recently which will help whoever tries to make code changes, but there's other things I think I can do too. Currently, the openstreetmap-website is both responsible for the openstreetmap.org web application, and for the API. How hard would it be to separate these two functions, perhaps even into two projects? That's exactly what we're working on with cgimap. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Talk-us] SEO Damage to OSM
On 01/07/17 11:48, Walter Nordmann wrote: Am 01.07.2017 um 08:33 schrieb Simon Poole: I've already touched on this with the sys admins and saved refs to the ones that I fixed. However it is unlikely that we will do any thing with the information as the accounts are extremely unlikely to be reused, and on the other hand, given that *we have a known US based SEO company that has created (literally) 1000s of such accounts* (but with slightly less spammy edits), and "we" haven't taken any action, why should we in this case? > what's about a captcha to disable automatic registration? and a confirmation mail, which is asking a variable question too? That's a very rosy view of captchas, which are now mostly an arms war between spammers and the innocent victims who get to try and decode ever more obscured captchas as the spammers get better at automating them. In any case most of the SEO related issues I have seen in OSM do not appear to be automated - they tend to give the appearance of being outsourced to India or the far east and done at least semi-manually. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Andy Allan joining web site maintainers
I'm pleased to be able to invite you all to join me in welcoming Andy Allan as the new co-maintainer on the code base for the OpenStreetMap web site. Going forward we intend to look to add additional maintainers to further diversify and spread the load, so we will be actively looking for candidates among those working on the code base. Please continue to open issues and pull requests on GitHub as before. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Programatic reconstruction of postal code areas
On 29/03/17 09:41, Jo wrote: For postal_code boundaries, they will very often follow existing boundaries, except where they don't... so I would say it is possible to draw them by mostly following the existing admin_boundaries. So now you appear to be talking about the UK which I do know about and which definitely doesn't have boundaries as such. Royal Mail as I understand it defines each post code by a list of addresses. They do also provide a centroid point derived from that list but I don't believe they provide any sort of boundary. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Programatic reconstruction of postal code areas
On 29/03/17 08:58, Frederik Ramm wrote: On 29.03.2017 09:10, Alex K wrote: * For one, this type of information is already part of OSM: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code Generally we don't like data that is impossible (or difficult e.g. "knocking on doors") to verify on the ground, but we do make exceptions for admin boundaries and, usually, postal code boundaries. If the postal code boundary is a genuine thing that exists then sure. I don't know about the countries in question, but in the countries that I do know about there is no such thing as a postal code boundary because the authority that assigns postal codes doesn't do so using geographic areas like that, and doesn't special any specific boundary. Rather they are just defined by a list of addresses, being a set of addresses that are a convenient group to deliver to. Now obviously you can draw any number of shapes around those addresses but none of those shapes is in any way an official or definitive boundary for the postal code. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Programatic reconstruction of postal code areas
On 28/03/17 22:24, Alex K wrote: Basically I'm using a semi-automatic process which takes all the know data points (e.g. buildings/nodes with an explicit postal code tagged to them) in OSM, generate voronoi cells and then merge them to larger regions. Then I do manually editing and clean up in my tool (aligning boundaries more nicely, reducing number of nodes, etc) and finally want to import the results as new relations into OSM. I did some evaluations on Austria against a real life data set and although the computed regions can only be an approximation, it did improve the quality of answers a lot! I did some basic write up of the details plus screenshots here: Invented non-real world data like this simply doesn't belong in OpenStreetMap I'm afraid. I mean feel free to generate these areas and make them available for geocoding etc but they're not real things and they clearly can't be verified by anybody because they don't actually exist. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 08/03/17 09:35, joost schouppe wrote: While a lot of the comments are a bit misguided, I think it is clear that quite a few mappers use this dirty trick to get the render to refresh. As OSM.org is supposed to be a mapper's tool and not a general public website, I think it is quite obvious that a forced-tile-refresh function is within the scope of the website. There is a cargo cult belief that you need to force dirty the tile at the renderer but that is almost never the case - any changes to nodes and ways will automatically dirty the relevant tiles. Only changes to relations are not handled automatically. Now there was a bug for much of last week where that wasn't happening properly - that was fixed on Friday morning and all the missed tile expiries were processed over the next 24 hours. What is normally an issue is the squid caches that sit in front of the renderers, but a simple shift-reload will bust those caches and in fact a manual dirty will do nothing at all to help with those. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC 17 : Refactor the DB schema for better usability on access patterns
Please note that there is considerable overlap between that project and some of the others, and I suspect the others have wider support. In particular there is Paul's "Make the website use the API" project which clearly overlaps with it. I think before time is spent on that project there needs to be a good consensus from the community that it is the correct approach or there is a risk of wasting effort on something that will never be used. That project would also appear to require C++ skills (unless it is proposing to dump cgimap completely) which are not currently mentioned. Tom On 06/03/17 10:31, Darafei "Komяpa" Praliaskouski wrote: Hello Pulkit, I'm Darafei, I proposed the project and ready to mentor it. First page to look at for this project is https://wiki.openstreetmap.org/wiki/Database - it describes the current state, used software, schema and links to relevant spots in software. I've done a small proof of concept implementation https://github.com/Komzpa/fastmap. It's not properly tested and not in any way integrated with any of API web services, although shows a lot better performance even without major schema refactoring. You can start with setting it up and playing in Postgres console, and try adapting test cases for /map call from cgimap onto it: https://github.com/zerebubuth/openstreetmap-cgimap/tree/master/test This will give you the most impression of what the project is about in shortest time. Don't hesitate to write to me directly, https://t.me/komzpa for Telegram, or @komzpa on OSM Slack https://osmus-slack.herokuapp.com/. вс, 5 мар. 2017 г. в 22:38, Pulkit Bhatia <pulkit4t...@gmail.com <mailto:pulkit4t...@gmail.com>>: Hello, I am Pulkit Bhatia, final year student pursuing B.Tech. Computer Science at Guru Gobind Singh Indraprastha University, Delhi. I am well versed with programming in Java, Ruby/RoR and also successfully implemented my GSoC 2016 project <https://github.com/celluloid/GSoC/blob/master/reports/2016-reel_features.md> with Celluloid <https://github.com/celluloid>. I was going through idea list and I am really interested to work on project *Refactoring the DB schema for better usability on access patterns.* Since I am new to community, it would be really helpful if I can connect with possible mentors for this project and also please guide/point me from where to start (issues/any reference/task). Thanks and Regards, Pulkit Bhatia github - github.com/pulkit4tech <https://github.com/pulkit4tech> linkedin - linkedin.com/in/pulkit4tech <https://www.linkedin.com/in/pulkit4tech/> irc nickname - pulkit4tech <https://www.linkedin.com/pub/pulkit-bhatia/98/ba4/25a><https://www.linkedin.com/pub/pulkit-bhatia/98/ba4/25a> ___ dev mailing list dev@openstreetmap.org <mailto:dev@openstreetmap.org> https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] HTTPS links to OSM tile server
Well probably one of the extensions (SlippyMap/SimpleMap) rather than something using OpenLayers... Tom On 05/03/17 14:08, Andrew Hain wrote: What should the wiki be using then? Is it part of the extension to display maps? -- Andtew *From:* Tom Hughes <t...@compton.nu> *Sent:* 05 March 2017 13:40:12 *To:* Wolfram Schneider; OSM developer list *Subject:* Re: [OSM-dev] HTTPS links to OSM tile server On 05/03/17 13:10, Wolfram Schneider wrote: Who is in charge of updating https://www.openstreetmap.org/openlayers/OpenStreetMap.js ? It seems that the file was last updated 3.5 years ago. That copy of OpenLayers is maintained for legacy reasons (because lots of sites stupidly loaded it from us) and the correct response to any problem with it is to switch to using an upstream version... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] HTTPS links to OSM tile server
On 05/03/17 13:10, Wolfram Schneider wrote: Who is in charge of updating https://www.openstreetmap.org/openlayers/OpenStreetMap.js ? It seems that the file was last updated 3.5 years ago. That copy of OpenLayers is maintained for legacy reasons (because lots of sites stupidly loaded it from us) and the correct response to any problem with it is to switch to using an upstream version... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap accepted for this year's GSoC
On 27/02/17 19:45, Peter Barth wrote: Besides I'm excited to tell you that the EWG tries to resurrect :-) Which is news to the EWG members I think. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 17:15, Дмитрий Киселев wrote: The key thing is that you need some mechanism for appointing people to that circle of maintainers who get to vote on which things should be included and which shouldn't. On most projects that is done by promoting from those making useful contributions, so it's hard to move in that direction until we can get more people involved. Going that way, maintainer will fall into approval buble, people who shares maintainers vision have higher chance to become a "good" committer, so feedback from users who doesn't share yours vison become smaller and smaller. Can you give me any example of an major open source project that accepts changes on the basis of self appointed voting - ie that says that so long as you can get N people to say they want it then it should go in no matter what? I agree that comments on gh isn't the message board, and not all commits should be applyed and authours/maintainers vision should be respected, but now we are in quite a weird state: Well that completely contradicts your previous paragraph. You can't say that there should be a person or persons in charge of looking after the overall vision and deciding what fits and what doesn't and then say that somehow feedback from "enough" users can somehow override that. We have discussion and voting procedure for tags even for the very specific tags, like electrical power scemes. Which works because the real mappers then just ignore the vote and carry on as before ;-) Seriously, the wiki tag voting is not a good example for, well, anything really. But for software, the community have no way to affect pull requests or roadmap items. Anybody can effect the "roadmap" because we don't have one. Like most open source projects we don't have people we can instruct to follow some roadmap so we rely on people writing code and offering it so that is how you affect the roadmap. Yes if you're not a programmer then that doesn't help you but I'm not sure what else would - you can propose things on github until you're blue in the face but if there's nobody interested in implementing them then it's not going to happen. As to "affecting pull requests" what I'd really love is a concrete proposal of how you think this would work - are you really suggesting that if enough people say "+1" then it should go in no matter what the maintainer(s) think of it? I think if you do that you will have trouble keeping maintainers involved. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 16:24, Дмитрий Киселев wrote: > at this moment, we have some widely used resources such as osm.org > and osm carto, started and threated as single persons gh repository. Actually carto has had multiple maintainers for some time. Indeed the original maintainer, who I assume you are referring to, is not actually doing very much these days. While osm.org has only one maintainer we have been getting some more contributors recently. Andy has been refactoring the tests to use factories instead of fixtures (a big job) and Herve has been updating the emails we send out to start with. And we (osm community) don't have a way to discuss and evaluate changes in collaborative way. That can certainly work, and I've discussed it with people in the past although not everybody has always agreed with the idea. The key thing is that you need some mechanism for appointing people to that circle of maintainers who get to vote on which things should be included and which shouldn't. On most projects that is done by promoting from those making useful contributions, so it's hard to move in that direction until we can get more people involved. Note that when I say vote here I don't necessarily mean literally as there are different models - some projects have a formal vote of some sort for each feature (often requiring at least one +1 and no -1 for example) while others allow maintainers to decide on their own but with a reversion mechanism if somebody objects. Note that you do need to preselect the voting group, otherwise anybody that can drum up enough +1's can get anything in. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 14:43, Blake Girardot HOT/OSM wrote: On Fri, Feb 24, 2017 at 12:33 PM, Dave F <davefoxfa...@btinternet.com> wrote: On 24/02/2017 11:19, Tom Hughes wrote: Well it was a little odd that we suddenly got several people who are not regular commenters turning up in the space of a few minute to add "me too" style responses. What's wrong with that? There are numerous discussions in Dev that I have no interest in, but on occasion there's something relevant to my OSM usage & I will make a comment. This current topic appears to be relevant to a few other users. OSM Github is not a private club. You should be welcoming other contributors, not 'closing' on them. I second this 100%! If something is of interest to someone and they know other stakeholders who have similar use cases or the feature is important to them, getting them to actually contribute their input is really an invaluable opportunity for developers. An issue tracker is not a general discussion board though, and there has to be some sort of limit to discussions there if we're not all going to be driven insane. The people that were turning up in this case were not saying adding new information by saying "I use that to do X" where X was something new that nobody had mentioned before that might change the balance of whether it was worth doing but rather they were just asserting that they used the feature like the previous commenters - they were adding quantity to the discussion not quality. I don't normally lock issues, so in the vast majority of cases people are welcome to comment on closed issues if they have some new information to add, and if that leads to a closed issue being reopened then that is fine. I lock issues when people are continuing to post in a way which is not useful and doesn't add anything - restating a position over and over again without adding new information is not meaningful discussion and when that happens I may decide to lock the issue. The alternative (to preserve my sanity) is that I simply unsubscribe from those issues and leave people to waffle on in an echo chamber but I'm not really sure that's better for anybody is it? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 11:27, Dave F wrote: On 24/02/2017 10:26, Jóhannes Birgir Jensson wrote: It was closed and rejected in a very abrupt and unconstructive manner. Yes. This seems to be Tom Hughes's default reaction. He's certainly trigger happy with the close button. Tickets can always be reopened. If I'm going to say no to something I might as well close it at the same time otherwise I have to remember to do so later. If there is a subsequent discussion that suggests there is a good reason to do it the ticket can and will be reopened. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 11:33, Dave F wrote: On 24/02/2017 11:19, Tom Hughes wrote: Well it was a little odd that we suddenly got several people who are not regular commenters turning up in the space of a few minute to add "me too" style responses. What's wrong with that? There are numerous discussions in Dev that I have no interest in, but on occasion there's something relevant to my OSM usage & I will make a comment. This current topic appears to be relevant to a few other users. The problem is that there is a subset of people that think tickets are a popularity contest and that if they can just get enough people to vote for a ticket it will be accepted/implemented/whatever. That's not how it works however, in almost any open source project in fact, because things are done because people want to work on them and are accepted when they are the right thing, whether they are being asked for by one person or a hundred people. Even if a hundred people turned up to say they would use this that tells us nothing about the other million mappers that have no idea what github even is so it's really not helpful to fill everybody's mail boxes up with "+1" messages that we're all just going to ignore anyway. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 11:11, Tom Hughes wrote: Rather what happened is that at some point (most likely in the 1.0.0 release about six months ago) leaflet started marking tile images with a CSS attribute that stops the browser offering image options for them in the default context menu. This is the actual commit to leaflet that caused it: https://github.com/Leaflet/Leaflet/commit/0cfe8589 in response to this issue, which unfortunately has no explanation: https://github.com/leaflet/leaflet/issues/2396 That then made it's way to OSM when leaflet 1.0.0 was release and we switched to it on 27th September last year. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 10:26, Jóhannes Birgir Jensson wrote: As evident in the discussion on issue https://github.com/openstreetmap/openstreetmap-website/issues/1446 there are several people interested in maintaining functionality that existed only a few days ago - being able to view single tiles just as easily as before. A patch was submitted which added the tile to the new context menu (which in itself is a fine addition but eliminated the functionality being discussed). See https://github.com/openstreetmap/openstreetmap-website/pull/1450 That is not an accurate description of what happened as I explain in my previous message. It was closed and rejected in a very abrupt and unconstructive manner. I respectfully disagree that I have been unconstructive. I have made clear that there are a number of ways that the requested functionality could be made available including in a detailed response I posted this morning which you in fact quote from. The issue itself was also closed with accusation of brigading. Well it was a little odd that we suddenly got several people who are not regular commenters turning up in the space of a few minute to add "me too" style responses. But removing functionality and then denying it to be re-added based on very little but personal objective is unhelpful and detrimental. Again that is not what happened. At no point was a decision made to remove this functionality. Rather it was removed essentially by accident when leaflet was upgraded and only six months later when we added our own context menu have people complained about it. What should have been a great patch with addition of context menu is turning into an issue because of one very simple change and resistance to tweaking it. Denigrating active mappers because they are "the 0.001%" of the user base is hardly a solid reason - nor is "what makes good UX for the 99% not what will make the 1% a little happier". It's not intended to denigrate anybody, it's simply to explain that we can't simply add everything that is of use to some small subset of users because there is a cost to everything both directly in terms of maintenance and indirectly in terms of complicating the UI for all the other users that will never use a given option. More specifically there were a number of people asserting that this feature was somehow to all mappers and I was trying to make the point that really that wasn't true at all and that the was majority of mappers would never have any use for it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
On 24/02/17 10:26, Jóhannes Birgir Jensson wrote: But removing functionality and then denying it to be re-added based on very little but personal objective is unhelpful and detrimental. As far as I know no functionality has been removed, at least not recently. Rather a request to add functionality has been declined. I assume you are referring to the fact that at one point it was possible to access this via the browser's context menu but the recent addition of our own context menu has not changed that in any way and you can still access that menu by holding down shift. Rather what happened is that at some point (most likely in the 1.0.0 release about six months ago) leaflet started marking tile images with a CSS attribute that stops the browser offering image options for them in the default context menu. I would quite likely accept a patch to override that CSS setting and restore access to the image options in the browser menu but I still do not think we should add such an option to our context menu which is inherently targeted at a more average level of user. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Odp: Re: Make Nominatim more dev friendly
On 02/02/17 09:53, Mariusz Rogowski wrote: By obvious steps I mean: 1. Make current maintainers stop working on existing issues (if they don't have time). The biggest issue right now is the project is not attractive to new developers. Fix that first. What I mean in details e.g. is: - Close pending (for years) pull requests. - Prepare nice project readme which mentions contributors are needed and welcomed. - Prepare documentation of existing code base. Things like architecture, languages used, test approach etc. - Prepare some contribution guidelines. - Prepare some big picture. Project is quite old, I guess technologies and architecture chosen might be quite obsolete. Maybe someone should review the current approach and decide on some bigger targets than fixing single small issues. E.g. sometimes I feel that that putting address data to some search engine could get rid of lots of logic in Nominatim code. Anyway, make the project as attractive as possible for new people. There are people who want to contribute to open source projects. You could get contributors from Google Summer of Code, Hacktoberfest, Hackathons and Code Retreats. But you need to make project look like it's worth ones time. Firstly nobody can "make current maintainers" do anything - that's not how open source software works. People work on the things they're interested in and maintainers do their best to make some sense of the results and construct a coherent result. More constructively, if you think those things are important then why not work on some of them? It seems like some of them at least are things that would actually be a good way for somebody who wanted to get involved could get started - as you explore the code and learn about it you can document what you find and submit that as a pull request to add new documentation where things are lacking? Likewise anybody could write a nice README encouraging people to get involved and I'm sure the maintainers would be happy to merge it. Or you could draft some contribution guidelines - those might need to go round a few cycles of review to fit with the maintainers preferences but much of the work of writing them could be done by somebody else and offering something (however minimal) is a constructive way of suggesting that some guidelines be added that will likely work better than complaining that they are missing. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap.org site statistics
On 16/12/16 12:08, Darafei "Komяpa" Praliaskouski wrote: I've changed the wiki page not to list awstats anymore. There is also stray entries on awstats in https://github.com/openstreetmap/chef/tree/master/cookbooks/stats and stray DNS entries in https://git.openstreetmap.org/dns.git/blob/HEAD:/src/openstreetmap#l218 Can Piwik be added to wiki to make the requested data publicly available? I can create a "site" for it in piwik, if somebody knows how to add the client code to the wiki. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap.org site statistics
On 16/12/16 11:47, Darafei "Komяpa" Praliaskouski wrote: I would like to get daily statistics on wiki page views:Â Â - URL; Â - User count; Â - Page view count (for page reopens); Â - Where user comes from (referrer), where they go afterwards; Â - Country / Language. This data should be available in Piwik. No it isn't, because the wiki doesn't use Piwik. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap.org site statistics
On 13/12/16 11:50, Darafei "Komяpa" Praliaskouski wrote: вт, 13 дек. 2016 г. в 13:55, Tom Hughes <t...@compton.nu <mailto:t...@compton.nu>>: On 13/12/16 10:33, Darafei "KomÑpa" Praliaskouski wrote: > It lists awstats for www, planet, and wiki. They all are down. Interesting. I wasn't aware that had ever been public. I think it does still try to run but frankly it's pretty hopeless with the volume of data we have I think. Looking at https://github.com/openstreetmap/chef/tree/master/cookbooks/stats - it should be public. No auth attempts that I see in configs. I just meant I wasn't aware it was, not that it wasn't meant to be. I think that was originally setup before I was involved, which shows how long ago it was ;-)  > What is current way to look at statistics on osm.org <http://osm.org> <http://osm.org> > visits, planet accesses and wiki popularity? I don't think there are any public statistics.  Are there non-public statistics? Ghostery extension suggests there is Piwik installation on osm.org <http://osm.org>. Yes we are running piwik. It's generally a tricky thing to do because of the privacy issues involved and the need to make sure things are aggregated into big enough buckets to avoid revealing anything we shouldn't. What exactly and why shouldn't be revealed? Well anything that can identify an individual, which might include aggregated values if buckets are too small. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap.org site statistics
On 13/12/16 10:33, Darafei "Komяpa" Praliaskouski wrote: It lists awstats for www, planet, and wiki. They all are down. Interesting. I wasn't aware that had ever been public. I think it does still try to run but frankly it's pretty hopeless with the volume of data we have I think. What is current way to look at statistics on osm.org <http://osm.org> visits, planet accesses and wiki popularity? I don't think there are any public statistics. It's generally a tricky thing to do because of the privacy issues involved and the need to make sure things are aggregated into big enough buckets to avoid revealing anything we shouldn't. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] planet.openstreetmap.org/replication policy
On 28/11/16 12:24, Oliver Tonnhofer wrote: I'm the author of Imposm 3 (https://github.com/omniscale/imposm3/) and I'm working on a new command that will automatically download and import diff files from planet.openstreetmap.org as they appear. Normally, it should only make two requests per minute when using minutely replication. One for the state and one for the osc.gz file. But after the initial import it will download the diff files as fast as Imposm can import them till it catches up with the live updates. A fast server should be able to process 100 diffs per second and more, especially when only a smaller extract is imported. My question: Is this OK, or should I add a throttle for this? As Yves said the best plan would be to use daily diffs until you get to the current day, then hourlies and only switch to minutelies when you get to the last hour. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Changeset meta 'comments_count'
On 20/10/16 15:26, Michael Larsen wrote: Changeset metadata contains the attribute 'comments_count' which I assume is the number of notes attached to a changeset. However, now I see that it is zero for changesets with comments, e.g. see the one below. I suspect this is a recent change? The API page does not mention this attribute AFAIK, so maybe this is an unused and deprecated feature? That call was recently switched to cgimap so this is likely a bug in the cgimap implementation of it. Please raise an issue here: https://github.com/zerebubuth/openstreetmap-cgimap/issues Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tile usage without proper identification
On 06/09/16 10:22, Rory McCann wrote:
On 05/09/16 20:19, Tom Hughes wrote:
Those instructions are about setting up a web based map which shouldn't
normally hit any policy restrictions.
Those pages have examples which refer to the main openstreetmap.org tile
servers? So the OSM.org tile usage comes into play?
Nothing in those instructions will cause requests to be sent without a
referer or user agent so there shouldn't be any problem with a site
which is built following those instructions?
If you're on a HTTPS site, and access a HTTP resource, browsers will not
send a HTTP referer. Those instructions have http:// links.
The simplest solution would probably be to change the URLs in those
documents to htts://{s}.tile.blah Then it will work fine with HTTP and
HTTPS hosted web pages.
Or just protocol relative links as //{s}.tile.blah indeed, but thanks
for explaining.
Hopefully the switch2osm maintainers will be able to make that edit.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap Carto release v2.43.0
On 06/09/16 01:33, Paul Norman wrote: Today, v2.43.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released. It has not yet been rolled out to the openstreetmap.org servers. I'll just add to this to say that on this occasion there will probably be a short delay as we are in the middle of working through a cycle of software updates on the tile servers. This release will likely be deployed next weekend once the third tile server has been upgraded. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tile usage without proper identification
On 05/09/16 18:17, Christian Ledermann wrote:
The Documentation on swith2OSM needs to be updated.
https://switch2osm.org/using-tiles/getting-started-with-openlayers/
and
https://switch2osm.org/using-tiles/getting-started-with-leaflet/
both use http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
My site https://schools.mapthe.uk becomes unusable after 20 views due
to the tile usage policy.
I assume this will be the case for a multitude of sites because either
the JS library has a OSMTileProvider
built in that points to tile.openstreetmap.org or OSM layer is
documented using this url.
I don't understand what you are saying...
Those instructions are about setting up a web based map which shouldn't
normally hit any policy restrictions.
Nothing in those instructions will cause requests to be sent without a
referer or user agent so there shouldn't be any problem with a site
which is built following those instructions?
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] tile log dates
On 26/08/16 08:56, Martin Raifer wrote: As you can clearly see, the dates mentioned in the logs' file names don't match up with the actual event. Could it be that the dates are off by one? Or is something else going on? As is pretty much complete normal the log files don't roll over at exactly midnight - if for no other reason than that it would be very hard for the log rotation process to do everything instantly. Rather the cron job that rolls logs over normally runs at about four in the morning or so and we then save the old file under the previous days date, so you will see some messages whose date doesn't match the name. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using API 0.6 to create a new node
On 15/06/16 12:37, Christian Ledermann wrote: yes you either have to include the oAuth token or the username:password It's not just a question of "including a token" but rather you have to properly sign the request according to the OAuth protocol. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM + iD + Nominatim Setup instructions
On 04/06/16 09:19, Stadin, Benjamin wrote: But there seem to be some places where the Nominatim URL is hardcoded instead of using NOMINATIM_URL. I'm not sure what that has to do with anything I wrote? I mean I said nothing about integrating your instance of the rails port with your instance of nominatim, mostly because I had no idea whether or not it was configurable! For example: https://github.com/openstreetmap/openstreetmap-website/blob/master/lib/nomi natim.rb Sure it's a bug - fixes welcome. https://github.com/openstreetmap/openstreetmap-website/blob/master/test/htt p/nominatim.yml (That’s a test case, but still why shouldn’t it use a configured URL to test the actual instance) Well a test shouldn't be touching a live server at all. and indeed it doesn't because that file is actual controlling the mock server that is used in testing - it lists the URLs and the responses that will be faked when those URLs are hit. So the test environment will always need to use NOMINATIM_URL pointing at the real server as that is the URL that the mocks respond to. Also all locale yamls (though that is less important I’d say): https://github.com/openstreetmap/openstreetmap-website/blob/7b96de31f7842ca f13da40dc71ff2d33146ad60b/config/locales/sk.yml Again, bugs, though probably a bit harder to fix. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM + iD + Nominatim Setup instructions
On 04/06/16 00:54, Stadin, Benjamin wrote: I¹m on a quest to setup an own instance of OSM, altogether with Nominatim and iD editor. iD should communicate with this very instance of OSM and not with the global OSM website. If you install your own copy of the website then the builtin iD should do that automatically. So really it's only OSM and Nominatim you are setting up. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: TCP Fast Open Experiment
On 02/06/16 17:47, Jeffrey Ollie wrote: On Thu, Jun 2, 2016 at 9:54 AM, Tom Hughes <t...@compton.nu <mailto:t...@compton.nu>> wrote: As and when whatever web server software our various sites use supports it then no doubt you will be able to. In the case of nginx (which this particular site is using) then I believe that it is new in the very latest version, or in the version about to be released, not entirely sure which. HTTP/2 support became available in the stable release of nginx in April when 1.10.0 was released. It's been available in the development versions for quite a while. Well that machine is running 1.10.1 so I guess it should be available. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fwd: TCP Fast Open Experiment
On 02/06/16 15:37, Florian Lohoff wrote: From my understanding TFO solves the problem HTTP/2 (or SPDY) solved by muxing streams of data into the same tcp connection or am i wrong? Related maybe, but HTTP/2 does a lot more than just that. What about HTTP/2 support? As and when whatever web server software our various sites use supports it then no doubt you will be able to. In the case of nginx (which this particular site is using) then I believe that it is new in the very latest version, or in the version about to be released, not entirely sure which. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Upcoming Planned outage - 9th May 2016
On 12/05/16 22:07, nebulon42 wrote: There was a specific, and unrelated, problem this morning that I have addressed. Is that what you are referring to? I'm not sure what the problem was and what was fixed. But I think what Gerd meant is that changeset uploads in JOSM seem to be slower than usual. From the opening of the changeset it takes more time to upload the objects than before (even for relatively minor changes). That's pretty much expected I'm afraid - the database is now several hundred miles away from the web servers so there is more latency. It will be interesting to see what happens tomorrow when we switch over to the backup web servers which are colocated with the database to cover this weekend's power outage at our primary site. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Upcoming Planned outage - 9th May 2016
On 12/05/16 09:48, Gerd Petermann wrote: it seems that this hardware change has slowed down the update performance, means, all my updates via JOSM took much longer until the changeset was closed. There was a specific, and unrelated, problem this morning that I have addressed. Is that what you are referring to? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis RuntimeException: Pipeline entities are not sorted
On 29/04/16 20:52, Gerardo Velez wrote: I’ve been using osmosis ver 0.44.1 to update my openstreetmap database for at least a month without any problem, but today trying to process http://planet.osm.org/replication/day/000/001/325.osc.gz change file I got the following error: SEVERE: Thread for task 1-read-xml-change failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Pipeline entities are not sorted, pr evious entity type=Node, id=199245, version=7 current entity type=Node, id=199245, version=7 There was an issue with the web server yesterday morning that led to one of the hourly diffs not finishing properly which in turn led to duplication in the next one. That then got folded into the daily which is created by merging the hourlies. I've emptied the failed hourly now, as I believe everything in it is also in the following one, and rebuilt the daily. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SSL-Certificate for osm.org
On 21/03/16 09:49, Oleksiy Muzalyev wrote: I would suggest contact engineers at Oracle who work on Java and explain them the issue. Perhaps, it could be solved in two weeks via Java auto update. The most widespread form of communication is misunderstanding. Perhaps, they are just unaware of it. Excuse me while I try to stop laughing. As far as anybody can tell the Java Root Certificate Program is some sort of black hole that applications go into but then nothing happens. See for example https://forum.startcom.org/viewtopic.php?f=15=1815 where there are five year old messages from StartCom people to the effect that they are trying to get Oracle to add their root. More recently letsecnrypt have applied but there has been no evidence of anything happening. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SSL-Certificate for osm.org
On 21/03/16 09:59, Tom Hughes wrote: On 21/03/16 09:26, Frederik Ramm wrote: Or perhaps there are alternative SSL stacks for Java that can be employed? No need for that, all it really needs is for the JOSM devs to be prepared to make it use a custom root certificate set until such time as Oracle get around to updating the default set... Basically doing the sort of thing talked about here: Apparently JOSM did exactly this a week ago: https://github.com/openstreetmap/operations/issues/55#issuecomment-199208093 https://josm.openstreetmap.de/changeset/9995/josm Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SSL-Certificate for osm.org
On 21/03/16 09:26, Frederik Ramm wrote: Or perhaps there are alternative SSL stacks for Java that can be employed? No need for that, all it really needs is for the JOSM devs to be prepared to make it use a custom root certificate set until such time as Oracle get around to updating the default set... Basically doing the sort of thing talked about here: http://stackoverflow.com/questions/24555890/using-a-custom-truststore-in-java-as-well-as-the-default-one?lq=1 Which creates a custom trust manager that tries both the default trust manager and a second one that has other roots loaded. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SSL-Certificate for osm.org
On 21/03/16 07:50, André Riedel wrote: 2016-03-21 8:06 GMT+01:00 Tom Hughes <t...@compton.nu>: Do we actually generate that name anywhere? or have you just assumed that you can change it to https? OSM does not generate https links, but other tools will do it or change existing ones. Well that would be wrong of them ;-) The guy who told it to us probably assumed such a behaviour. But I would support his thoughts. I think we do have a certificate that has it, but we can't use it on the main site because it will break JOSM. The horribly backward Java certificate root authority list is the main obstacle to most of our attempts to improve https support in fact. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SSL-Certificate for osm.org
On 21/03/16 06:16, André Riedel wrote: We've got a bug report at the Chemnitzer Linux-Tage. osm.org should be added as alternative name in the openstreetmap.org certificate. This is important for the link shortener. https://osm.org/go/0MIaEuZzQ-?m= Do we actually generate that name anywhere? or have you just assumed that you can change it to https? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Minute replication hiccup
On 12/02/16 12:17, Roland Olbricht wrote: something strange has happened to http://planet.osm.org/replication/minute/001/788/263.osc.gz Yes, exactly the same thing as the last N times you asked ;-) The machine crashed, and because osmosis doesn't fsync the state file the last state was lost and Matt had to reset it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Usage of the standard dev server
On 03/02/16 21:51, markus schnalke wrote: Adding https is also a bit tricky at the moment I think, but should be possible if/when we switch to letsencrypt. That would be great and important, because HTTP Basic Authentication should not be done unencrypted. In developing an editor, one would want to ensure that the API is always called via HTTPS, if HTTP Basic Auth is to be used. Testing such an editor is thus not possible with the testing API. If you're developing a new editor you should be using OAuth not HTTP basic auth. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Usage of the standard dev server
On 11/01/16 13:16, Pichler, Markus wrote: It says on that page that the dev server is mostly empty, but if you go to the page http://api06.dev.openstreetmap.org/ it shows the entire world, just like the main openstreetmap.org site. However, if I do a download request in JOSM, it is empty. So my question is: Why is the map not a representation of the database on the dev server, showing basically nothing except in those places where somebody uploaded something for test purposes? Or am I missing something here? Because we don't setup a special tile server for each dev API so the tiles are just the normal ones you see on the main site. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
On 27/11/15 09:44, Gerd Petermann wrote: Do we have a database design that stores each OSM element with numerous columns for all possible supported attributes? I guess that would explain why there are technical limits. Yes the current schema has one column for each tag, but obviously limited to certain tags chosen when the database is created. So there is a highway column, a waterway column, a name column and so on, which the value being the value of the tag in question, or null if the object doesn't have that tag. So it's obviously quite wasteful to create hundreds of columns for relatively rare tags that will be null for most records. Hence the reason the tools how have the option to store some or all tags in a single hstore column - that's basically a column whose value is a hash of keys and values. You can read more here: https://github.com/openstreetmap/osm2pgsql/blob/master/docs/usage.md#hstore So the idea is that at the next reload some of the rarer key values would be moved into an hstore column, and that extra tags could be included in that set. It does need some matching changes to the style sheet though, as the syntax for SQL queries to select on values in the hstore will be different to the condition for selecting on a normal column. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
On 27/11/15 08:13, Gerd Petermann wrote: - Whatever DB design is used now is considered to be unable to store more attributes without changing the DB design. No that's not true, More attributes can be added, but only when a full reload is done. I mean we could add the extra columns to the existing database, but they would only get populated for changes made after that date and wouldn't be backfilled with values for existing objects. In theory somebody could write something to read the planet and backfill those columns but I don't believe it exists currently. - it was decided that the new design has to use hstore No, it was decided that it probably makes sense to use hstore for the less common attributes because it means you're not creating lots of columns that are mostly empty. Whether hstore or new columns are used doesn't really matter - in either case adding the column without a reload would mean the data was missing for existing objects. - nobody has made progress understanding how hstore works since then. I have no idea why you think this. We understand perfectly well how it works and plenty of people have stylesheets using it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] setting up mirror
On 18/11/15 17:02, Kevin Mcintyre wrote: Hello - I'm seeking information on setting up a planet osm mirror. I think the reason you're not getting replies is that you're asking for something that doesn't really exist - there isn't any general infrastructure for mirrors in existence. We have one mirror that we redirect most downloads to, and that's it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Registering on osm.org with a social account
On 12/11/15 13:58, Ilya Zverev wrote: We at maps.me (well, me alone for now) are looking into simplifying OSM sign up process on mobile devices. As you know, the current process, which involves opening a browser, then opening a mail app, then opening a browser again, then returning to an app and entering credentials once again, is quite disruptive. But since we already support linking accounts to social login services (like Facebook and MS Live), there are few things that could simplify registering users on mobile. I wrote some thoughts on hackpad: https://hackpad.com/Facebook-Registation-for-OSM.org-4MI6M5EeeRh Well there are many, many things wrong about that document. Firstly for social signup it is better to click the button on the login page, not start from the signup page. Yes that isn't good design and we really need to merge the two. Secondly, we already prefill the email if the service provides it, so no need to enter it once, let alone twice. In fact in some cases we even trust the email without verifying it. There's also no requirement to enter a password if you use social signup and I believe the page makes that clear. Basically if you click a social login button on the login page then your "alternate flow" is pretty much what already happens. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New Map Style feedback
On 01/11/15 17:09, Amaroussi (OpenStreetMap) wrote: The ability for OSM to render the “British” colours alongside the new style colours would depend on what resources they have, but I will support adding an alternative layer to the main site that uses the “British” colours, as soon as the alternative tile server goes live: it is clear that there is no clear standard for how roads are coloured. I will suggest however that the “British” stylesheet be based from the main openstreetmap-carto style, in order to ease maintenance. Why do you think a British style should get special treatment I wonder? Should we have a French style and a US style and a Chinese style and... I mean how exactly do you propose to decide which national styles should get special treatment? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian
On 30/10/15 01:11, Yuri Astrakhan wrote: At the State of the Map conference, some OSM developers were discussing the possibility of migrating osm.org <http://osm.org> to the vector-based backend. I would like to get some feedback on feasibility and desirability of this effort. Well I think everybody thinks it's desirable and will happen at some point now that there are various options starting to mature as far as underlying technology stacks go. Really though it's up to the stylesheet team - they're the ones that are going to have to do a lot of work and only once we have a style would we need to consider what stack to run it on. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Indic fonts on OSM tiles
On 06/10/15 16:42, Anish Mangal wrote: I was trying to generate map tiles in Hindi language and I noticed that the rendering of names of a few places is off, perhaps due to the font chosen. I tried with two fonts: 'gargi', which is the manilk default (i think) for devanagari 'lohit', another font which is freely available and widely used. In both cases, the rendering was off. Correct rendering (example): http://picpaste.com/delhi_good-gDYODgsB.png Incorrect rendering (example): http://picpaste.com/new_delhi_bad-NM9l7Dg2.png The name of the place in the above pictures: (New) Delhi Any pointers on how to fix this? Upgrade to mapnik 3. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Internal Server Error
On 28/07/15 07:14, Tom Hughes wrote: On 28/07/15 01:01, Walter Nordmann wrote: may be you could check your server logs and give me a hint. came from osm.wno-edv-service.de They are unlikely to tell me anything that I can't already guess. Basically there is something wrong with your request and the OAuth signature check is failing. The logs do not provide any detail because there isn't really any way they can - all they know is that the hash they computed does not match the one you sent. As I suspected, what we have is: NoMethodError undefined method `create_request_token' for nil:NilClass /var/lib/gems/1.9.1/gems/oauth-plugin-0.5.1/lib/oauth/controllers/provider_controller.rb:18:in `request_token' which basically means you have hit this: https://github.com/pelle/oauth-plugin/pull/143 but the reason there is no client_application is likely that signature verification failed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Outdated web pages / default pages on some OSM addresses
On 19/04/15 11:12, Peter Wendorff wrote: even if they have never been published I think a HTTP-Page that has the same URL than the HTTPS version should redirect to the HTTPS equivalent or show a hint that the https version exists. Which appears to answer an entirely different question to the one I asked. I asked why either should be expected to work. You have taken that as a reason to push for https as default, which is an entirely different issue. If not published somehow URLs are still often shown without protocol to a user (well - most often in those case they are prefixed with www.), and users are used to not type in the protocol prefix by hand. The protocol being used is not the point. The point is that neither site had been configured, because neither is a URL that we have ever told anybody to use! You might as well ask why fraggle.osm.org doesn't redirect to osmfoundation.org. We have dozens of domain names, and as things stand we haven't written anything to handle automatically managing all of those for all of the dozens of sites we have so you should, unless told otherwise, assume that only the published name (normally *.openstreetmap.org or *.osmfoundation.org) will be supported. If you want to write chef recipes to handle automatically setting up all the different domains then please be my guest. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Outdated web pages / default pages on some OSM addresses
On 18/04/15 18:54, Michael Kugelmann wrote: https://foundation.osm.org/ shows some information that the SOTM 2007 Manchester is over... (which is correct, indeed ;-) http://foundation.osm.org/ shows a Apache2 Ubuntu Default Page... Where have those URLs ever been published as valid URLs for the foundation web site? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm.org website translations
On 08/04/15 13:38, Tomas Straupis wrote: How often are translations loaded from translatewiki.org to openstreetmap.org? Or should I somehow request that? Currently month old translations (Lithuanian ones) are not loaded yet. That's entirely up to the people at Translatewiki - they push them to us whenever they feel there are enough changes to justify it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Line breaks in changeset comments
On 01/04/15 22:27, Antje wrote: I recently posted a changeset comment with line breaks but they do not show up – well, at least in practice. Example of the issue. - http://www.openstreetmap.org/changeset/29891202 Check the HTML code of the page: the line breaks are where the paragraph tags end and then start. Changeset comments, like notes, are treated as plain text because they need to be rendered in a narrow side bar so allowing full markdown is not really a good idea. A double newline will therefore be required to get a paragraph break. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Build Errors
On 10/03/15 14:27, Harvey Sama wrote: Ok. I tried to build the project using ant. I get the following error; C:\Users\Harvey\eclipseLuna\josm\build.xml:220: javac doesn't support the createMissingPackageInfoClass attribute I tried using java, but I get a list of 100 errors With eclipse, I had some JDK problem but I solved it. The application runs from eclipse and I can open the main application. Can I continue from here? So first things first, you should really specify what it is you're trying to build, not just say the project and hope we can figure it out. From the error message it looks like the answer is josm, in which case you will probably get much better answers from the josm-dev list than this general list. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GitHub repositories
On 05/03/15 20:30, Jakob Jarosch wrote: I'm one of the original developers of the OSMembrane GUI tool for osmosis. It hadn't a real maintenance but looks like the source code is now on GitHub. I would like to give OSMembrane another try and update the GitHub repository with the latest build and a README. Is there anyone who can give me access to that repository so I can add a release? URL: https://github.com/openstreetmap/OSMembrane Well I'm not sure who added it to the openstreetmap organisation. I'm an admin for the organisation but I've never even heard of it. i suspect it has been there for a long time. In a literal sense I could given you access, but I would want the current owners (whoever they might be) to approve that before I did so, so you should probabyl start by trying to contact them. It looks like https://github.com/podolsir is the only person with access to that repo (other than the org admins) so that is probably the best person to contact in the first instance. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Flagging of Changeset discussions
On 31/01/15 21:06, Dave F. wrote: Are replies to changeset discussions meant to be flagged in a users 'My Messages'? ATM it appears to not do that. Is there a reason it's not implemented? Changeset comments and user to user messaging are two completely different things. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] No more PBF planet files?
On 28/12/14 18:47, Sven Geggus wrote: looking at the current osm planet file I only find osm.bz2 Versions. While http://planet.openstreetmap.org/planet/planet-latest.osm.bz2 is from 2014-12-22 http://planet.openstreetmap.org/pbf/planet-latest.osm.pbf is still dating back to 2014-12-07 An Idea? I'm not sure what happened to the dump for the 17th but the 22nd failed because we switched to using planet-dump-ng to do the planet dumps last week and there was a bug in the driver script that meant the PBF was not copied into place properly. The bug has now been fixed: https://github.com/openstreetmap/chef/commit/1c048ed52745380fcc07c1e44c6bbb34d790dbe7 So this weeks dump should be fine. I thought the PBF dump had been lost but I just realised it was actually still in the temporary directory where it is created so I have moved it into place manually now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Wiki no longer shows diffs
On 20/12/14 10:14, Minh Nguyen wrote: For the last day or so, the wiki has been showing blank diffs for every edit, for example: http://wiki.osm.org/w/index.php?diff=prevoldid=1060762 Not sure what happened, but it's making it difficult to track changes on my watchlist. Thanks in advance to the sysadmins for looking into the matter. Actually it was only broken for about 16 hours and it was fixed nearly 24 hours ago now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Wiki no longer shows diffs
On 21/12/14 08:37, Minh Nguyen wrote: On 2014-12-21 00:34, Tom Hughes wrote: On 20/12/14 10:14, Minh Nguyen wrote: For the last day or so, the wiki has been showing blank diffs for every edit, for example: http://wiki.osm.org/w/index.php?diff=prevoldid=1060762 Not sure what happened, but it's making it difficult to track changes on my watchlist. Thanks in advance to the sysadmins for looking into the matter. Actually it was only broken for about 16 hours and it was fixed nearly 24 hours ago now. Yes, I know. My post was held in moderation for a day. Thanks for taking care of the issue. Sorry, hadn't realised (a) it was the same email as on talk and (b) it had been delayed. While we’re at it, the search bar no longer jumps directly to a matching page title; it always goes to the search results page. Is that intentional? No idea, you'd need to ask Grant. Unless it relies on an external component (like the diff does) then it's unlikely the OS upgrade on Friday changed it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [meta] Problem with reply to messages from mailing list on Gmail
On 11/12/14 17:32, Mateusz Konieczny wrote: I have a problem with mailing list - using reply is addressing e-mail to just person that submitted message, not the entire mailing list. http://webapps.stackexchange.com/questions/37046/making-gmail-to-use-reply-all-automatically-in-mailing-list-replies indicates that there is no easy fix Surprisingly replying to messages from tagging mailing list are automatically addressed to mailing list, despite the same addressing scheme. The tagging list is probably configured to set Reply-To and this one isn't (it's a per list option). No matter what anybody will tell you (and please, let not have the Reply-To for mailing lists flame war yet again) there is no right answer as to whether or not to set it. People have been debating it for at least twenty years. Anyway, I just tried gmail, and reply to all certainly included dev for this message as I would expect. Reply doesn't obviously. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Chinese spam diaries, an analysis
On 04/12/14 11:17, Andreas Labres wrote: On 03.12.14 17:14, Andy Allan wrote: Thanks for the analysis, I hope it provides developers with ideas for combatting it via the automated spam filters that we already have[1]. I'd suggest to extend/refine the automated filter somewhat. Say: * a novice ist not allowed to post at all * a novice who did some changesets is allowed to post say once per day * an intermediate is allowed to post say once per hour * for an expert (either subscribed for years or lots of changesets) the posting limit is waived So in other words, most of things we already factor in to our spam scoring... We're just not quite as rigid. In particular you can still post (within reason) without having made any edits - it is actually surprisingly common for non-spammers to do that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Chinese spam diaries, an analysis
On 03/12/14 16:14, Andy Allan wrote: However, spam is an arms race, and I think we might need a different long-term approach. I know in the past using 3rd-party spam filtering services was too expensive (and not really very OSM-ish either). The main such system is akmiset and I'd love to use it but (a) it costs money and (b) to make it most effective we would have to send it things like email addresses and IP addresses which I figure people may object to. Perhaps we need a new set of human content moderators on the site, say 40-80 people with a variety of languages between them. We can consider grey-listing all accounts - i.e. the first few posts of every account is held for review automatically by default, and enable direct posting after we're more certain they aren't a spammer. Once we have a review queue and moderator system then obviously it becomes trivial to do things like holding posts from new users for moderation - we need the basic infrastructure first though. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
