Wikipedia:Reference desk/Archives/Computing/2018 March 29

Computing desk
< March 28 << Feb | March | Apr >> March 30 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


March 29 edit

Google map correction edit

I live in Ukraine and Google map Maps has a small error that means that Uber taxis never take me to my door unless I explain, which is difficult because I don't speak Russian or Ukrainian. (Google maps shows buildings with number 56 on my street; one is correct but mine should be 56A. What I don't know is why Uber always takes me to the actual 56 but never mine.) It's only a problem when I have heavy groceries or something like that.

I tired tried submitting a correction online but nothing has changed. Can anybody give me advice? (Apart from learning to speak Russian or Ukrainian?) Hayttom (talk) 17:54, 29 March 2018 (UTC)[reply]

@Hayttom: Do other mapping programs (Apple maps or whatever) get it right? If so, you could show the drive the correct location on your phone from that app. RudolfRed (talk) 16:17, 30 March 2018 (UTC)[reply]
@RudolfRed: I have heard that Apple maps do get it right, but I can't show the driver an Apple map because I use Android. And the main goal here is to be able to specify my door in the Uber app, which uses Google Maps. Hayttom (talk) 10:26, 31 March 2018 (UTC)[reply]
In some places 56A would not be a different building from 56, but maybe a specific way into the building. I used to live in a building where 141A meant Apartment A in the building at 141. Maybe someone programmed Google Maps to ignore letter suffixes? --69.159.62.113 (talk) 21:40, 31 March 2018 (UTC)[reply]
I fairly doubt Google Maps doesn't support number-letter addresses at all. For example 7A Stone Hill Road, Springfield Township, NJ, USA seems to work. As do 56A Troy Drive, Springfield Township, NJ, USA; 56a Broad Street, Newark, NJ, USA; 56B Suburbia Drive, Jersey City, NJ, USA; 56B Henry Avenue, Palisades Park, NJ, USA etc. It may be address letters were ignored for certain locations for whatever reason. Nil Einne (talk) 07:21, 1 April 2018 (UTC)[reply]
Thank you, @RudolfRed:, for your logical suggestion. Actually I agree with @Nil Einne: that this is not the case, at least, here in Ukraine, but I'm grateful for your help.

You mentioned you tried submitting a correction. Does that mean you only tried submitting a correction to Google Maps and never contacted Uber? Because while the former was worthwhile, the later seems the other obvious step considering that Uber is a massive company and it's their service that is really the main issue for you. It's also what Uber suggested here [1] It seems easily possible either that they have more experience getting corrections onto Google Maps than you or the Uber app has support for Uber adjusted locations (i.e. the fact that they're using Google Maps doesn't have to mean everything would work exactly as Google Maps).

Also, are you sure you can only specify exact addresses? While apparently you can't specify GPS coordinates [2], various sources like Uber themselves [3] seem to suggest you can drag the drop off pin to adjust it. While apparently drivers hate this and so may ignore it, at least in the US [4], it's worth trying especially since I wouldn't be completely surprised if drivers in the Ukraine are perhaps more used to the addresses being problematic. Admittedly I'm not sure if this feature is supported everywhere [5]), the previous blog post seems to be from India which is another country where I wouldn't be surprised this features is needed.

Anyway while not really a solution to fixing the incorrect address, if the explanation is not very complicated and so shouldn't require two way interaction, you could just record a friend, or alternatively get a written out message which you can play back with text to speech software to tell the driver. Also is 56 the best address for where you're going? I suspect it would be, but consider whether there is a different address that is closer so you don't have to walk so far even if it's still the wrong address.

Nil Einne (talk) 07:13, 1 April 2018 (UTC)[reply]
@Nil Einne:, SPLENDID answer. Yes, I had only tried submitting a correction to Google Maps but I have just now tried telling Uber, via the app your link led to. (I haven't yet tried adjusting the drop-off location pointer they way you suggest, but will try next time. Meanwhile "56" is in fact the best address I can submit, but your idea of using a better proxy was also excellent.) NOW THERE'S MORE: I just noticed that when I click on my actual apartment building (that is labeled as '56') it pops up a window specifying that I have clicked "Another Street, 56", where "Another Street" is about 75 metres away (and the two do not intersect). (This would be analogous to Mr Trump's house being shown in the right location, but tagged as "1600 Virginia Ave NW".) I've explained this to the Uber page, have received a note saying "Thank you. We've received your message and will be in touch as soon as possible.", and will wait as patiently as I can, and I will try to learn how to tell the drivers what I need. Already I can say "please turn right" to normal taxi drivers in Russian, but to request a left turn I have to go clockwise around a block, turning right three times. Hayttom (talk) 09:54, 2 April 2018 (UTC)[reply]
Uber just wrote back to me, completely missing my point of course. Next time I ride Uber home, I will experiment by specifying the address string which is incorrect for my building's address, but which is pointed exactly at my building's location, and see what happens. Hayttom (talk) 14:59, 2 April 2018 (UTC)[reply]

Z-fighting effect on STL models edit

Hello!

I created a few STL files below and found that artifacts appear in the Wikimedia viewer and occasionally the thumbnail. I've checked that the direction of facet vertices is anticlockwise, the normals are sensible and polygons are not duplicated. It seems to happen more where the polyhedron is thin. All these polyhedra render correctly on http://viewstl.com . Would anyone know how to fix these artifacts?

Thanks,
cmɢʟeeτaʟκ 19:20, 29 March 2018 (UTC)[reply]