Updates portuguese strings.xml

[rjvitorino]

As requested by @barbeau , here are the portuguese translations.

I've done them as I understood the XML file, they might be too big for some layouts, I don't know. When the beta version is released I'll do a tour of the app and check if anything is wrong. Either way, it would be great in the future to have some screenshots of the "new" layouts, to better understand the strings context. :)

The License was not translated since I don't think it should be (I haven't found an Apache License written in other language rather than English).

Keep up the good work! Best regards

[vreixo]

@rjfv Thank you very much for your translations :-)

On a side note, I have detected a little issue with your server which is in #395, at first comment. If I'm right and sever limits are bigger than the covered region, on this thread there is also a quick solution to download a reduced version of OSM data.

Sorry to bother you with this, but might be important if for example someone in west Spain uses the app and is selected in your region by error or to prevent possible problems in the future.

Thanks again :-)!

[barbeau]

Thanks @rjfv! I'll likely take a look at this on Monday.

[rjvitorino]

@vreixo I read what you said on #395 and I believe you are wrong about Portugal. For the last two years, OST has been working with several data providers, mainly related to public transportation, such as the following:

• SMTUC (a Coimbra based mass transit agency)
• CP (a major nationwide railroad agency)
• STCP (Oporto mass transit bus agency)
• MoveAveiro (Aveiro mass transit agency)
• Carris (Lisbon mass transit bus agency)
• Transdev (nationwide intercity bus agency - still importing…)

These are used on our instance of the OpenTripPlanner, that's why we need a nationwide OSM file.

[vreixo]

@rjfv my apologies, I certainly misunderstood the situation.

I have just tried to plan trips around Lisboa, Faro, Braga, Porto and other aleatory points in the map and always obtained "A regiao nao esta a responder", now I have tried actually writing city name and I have received correct trips from Coimbra to Lisboa, Braga and Porto, so sorry again. I'm just wondering if timeout will be too small and that's why was not possible, in my tests, to route to areas not exactly in the cities, because I don't get "fora da cobertura da regiao". If timeout is negatively affecting your server we can change this in the app.

Clearly, setting origin and destination closer to big cities, server worked great! Congratulations for such an amazing project, with that number of providers and huge coverage :-)

Related to #395 I'm seeing now that you're exactly covering Portugal and the bounds square (in the app) is very big because of Funchal. I was a bit worried because some part of Morocco and Spain are inside the square, but this is because of the irregular shape of Portugal, thus may be interesting in the future to make a more complex process to detect user's region.

So, thanks again for maintain this huge server and for all your contributions to the app :-)

[rjvitorino]

No problem @vreixo :)

Regarding our OpenTripPlanner instance, I hope to have a bit more time in the near future to update the application and improve some things, being one of them the OSM data file we use. We just download the portugal.osm from http://download.geofabrik.de/ which includes Madeira's islands, even though we don't know any data provider there. I also want to take a calmer and closer look to your thoughts and contributions about elevation data (#395), so I will read the thread again soon.

If you're aware of any up-to-date OSM file concerning Portugal that we may use instead of the one I've mentioned before, please let me know. That is also valid for any improvements you know we should make to our OpenTripPlanner (timeouts and so on), so all the contributions are more than welcome :)

Thank you very much for the compliments about the OST project, we hope we can improve it further and take it to other places in Europe.

[barbeau]

Thanks @rjfv!

[rjvitorino]

No problem! Guys @barbeau and @vreixo I've noticed an issue on the Play Store app's description:

Portugal

• Coimbra
• Porto
• Madeira

when there should be no reference to Madeira (unless there is another OTP instance with data there). We have Lisbon's Carris (bus) data though :)

[barbeau]

@rjfv Thanks for the heads up. I'm now realizing that we do have overlapping OTP instances (I believe) for Portugal.

Check out entries 6-8 in the OTP Server Directory: https://docs.google.com/spreadsheet/ccc?key=0AgWy8ujaGosCdDhxTC04cUZNeHo0eGFBQTBpU2dxN0E&usp=sharing&authkey=CK-H__IP

@rjfv Would you be able to take a look at these servers, and if necessary contact the maintainers there, to figure out how you all want to cover Portugal? Also, are you saying that Lisbon should be listed in the Play Store description as well?

@vreixo Another reason for improving process of adding new servers (#410).

[brecke]

Hi there,

My name is Miguel Laginha and I work with @rjfv in the OST platform. Regarding the overlap that you mention, it is something that is difficult to avoid because OTP for Android works by associating servers to bounding boxes. The current situation in Portugal is that the One.Stop.Transport platform has data from all over Portugal - official data, some of it updated daily - while Transportespúblicos.pt has both official data (from the cities of Maia and Braga) as well as crowdsourced data in other cities (according to this link).

In the Northern region of Portugal, Maia and Braga overlap geographically with the national railroad agency (Comboios de Portugal) and there is nothing one can do about it. I guess that you have to choose either the www.tp.pt server or the www.ost.pt one.

Anyway, I will contact the guys from "Transportespúblicos.pt" so they can contribute to this thread and maybe they'll help us finding a solution.

Thanks.

[barbeau]

@brecke Ok, thanks for looking in this.

@vreixo I believe that as long as "sub-regions" appear earlier in the OTP directory than "super-regions", the sub-regions should still be selectable, right? In other words, if the user's location falls within the subregion, that region would be selected, but if not, and the user's location falls within the larger region area (that also contains the subregion), then the larger region area would be selected?

[vreixo]

@barbeau that's correct. App scans directory in order and the first server that matches the user location will be selected and search stopped.

Of course if auto detection is disabled user can choose whatever server he wants.

As a future option we might consider to offer to the user the option to choose a server if more than one matches his location, although we are going to lose some automation. El 23/9/2014 18:07, "Sean Barbeau" notifications@github.com escribió:

@brecke https://github.com/brecke Ok, thanks for looking in this.

@vreixo https://github.com/vreixo I believe that as long as "sub-regions" appear earlier in the OTP directory than "super-regions", the sub-regions should still be selectable, right? In other words, if the user's location falls within the subregion, that region would be selected, but if not, and the user's location falls within the larger region area (that also contains the subregion), then the larger region area would be selected?

— Reply to this email directly or view it on GitHub https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/pull/442#issuecomment-56544998 .

[rreisdasilva]

Hi Sean, Hi Vreixo,

Miguel contacted me about the overlapping regions. I was aware of OST project in Coimbra but unware it had expanded to include the whole country.

I was discussing with Miguel that the overlap is mostly geographically. There may be some places where we have data from the same transport company, but mostly we cover different companies. This means that it can happen that a user gets the "wrong" server (the one without the data he needs) selected...which may be a problem...

I guess this is now happening in Portugal for the first time but it will likely happen elsewhere given the natural spread of the app.

I don't know how Miguel sees it, but I see the "competition" between TransportesPúblicos.pt and OST quite nice because we have different approaches which results in convincing different companies. The silver lining is that one way or the other the information is available online for the public. Getting things combined will feel like a natural step in the future...

In this spirit, I would say that disabling default auto-detection is probably the easier thing to do, giving the users the chance to choose which server to use. I believe the loss in automation is minimal and not problematic

Any thoughts?

Ricardo

[rjvitorino]

Hello all again,

In my humble opinion, I don't think a manual server selection is a good choice. End users should not need to understand how the system works, neither to know the transport agencies on their location, that should be transparent.

I believe if someone is in some random city using OpenTripPlanner for Android and receives a server choice prompt, it would fright him out. Either way, how should he know which is the correct server/agencies? That's the beauty of OpenTripPlanner, you choose the starting point, the destination and the start time and you get N itineraries, you don't need any know-how about the transport network.

That is my point of view, I think it would be better if the application iterates through the server list whose bounding boxes contains the user's location and calls each server's API URL. From all the results choose the best N itineraries (3, 5, whatever) and display them to the user. What do you think?

Regards, Ricardo Vitorino

[rreisdasilva]

Hey,

Iterating through the several server and choosing a few options seems to be a valid option. Note sure how it will affect performance, though...In any case whatever the final solution will surely not be a deal breaker for me.

My arguments for the user choice option however, are as follows: As a user not only of OTP, and I agree I'm not the typical user, I like to be informed of what is happening, and I am not too happy when people make the decision for me. If there is only one option, there is no choice to be made, if there are several, I don't think we should assume what people want. People don't necessarily want to know the route, they may want to go with a certain project rather than another.

I am a big fan of open source software not because every open source software is always better than any proprietary software, but because I like the concept, like the project and the philosophy behind it, I trust certain developers, etc etc.

I feel users that are expecting to use OST would be disappointed if they got a result from TransportesPúblicos.pt and the other way around. Simply because their expectations would not be met. The app is the same, but the way to handle the data is not, the concept behind the options are not, the way to interact with the transport companies is not etc. So somehow I feel like cheating on users by not telling them what they are actually getting.

But like I said, these are just my thoughts on the matter, and whatever solution won't be a deal breaker.

Cheers, Ricardo

[barbeau]

@rjfv @rreisdasilva @brecke Thanks for your feedback on this issue! Since this is turning into a more complex issue than I originally thought it would be, I opened a separate ticket to discuss overlapping regions (https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/issues/452). I'll be tagging you shortly there so we can continue the discussion.

[barbeau]

@rjfv I just realized that we don't have an ICLA on file for you. Would you mind filling out our electronic ICLA, as discussed here?

It should only take a few minutes. Thanks!

[rjvitorino]

@barbeau thanks for the heads-up, it's done! :)

[barbeau]

Thanks @rjfv!